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PREFACE 

This  paper  is  the  result  of  work  performed  by  the  Institute  for  Defense  Analyses 
(IDA)  under  contract  number  MDA  903  89  C  0003,  task  order  T-D6-554,  "Measurement 
Issues  in  Unified  Life  Cycle  Engineering."  This  work  was  performed  for  the  Air  Force 
Human  Resources  Laboratory,  Logistics  and  Human  Factors  Division,  and  the  Under 
Secretary  of  Defense  for  Acquisition  (USD(A)). 

This  paper  specifically  addresses  the  management  and  organizational  issues 
surrounding  concurrent  engineering  teams  and  their  meetings  and  identifies  the  types  of 
computer  support  that  would  be  beneficial  to  the  group  problem  solving  activities  of  the 
concurrent  engineering  teams. 

This  paper  was  reviewed  by  Dr.  Paul  Richanbach,  Strategy,  Forces  and  Resources 
Division  (SFRD),  Dr.  Dick  Cheslaw,  Cost  Analysis  Research  Division  (CARD),  and  Dr. 
Jim  Pennell,  Computer  and  Software  Engineering  Division  (CSED),  Institute  for  Defense 
Analyses  (IDA). 
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SEE 
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Total  Quality  Management 

ULCE 

Unified  Life  Cycle  Engineering 

USD(A) 

Under  Secretary  of  Defense  for  Acquisition 

WBS 

Work  Breakdown  Structure 

EXECUTIVE  SUMMARY 


Concurrent  engineering  is  a  systematic  approach  to  the  integrated,  parallel 
development  of  products  and  their  related  manufacturing  and  support  processes  to  increase 
customer  satisfaction.  TQM  is  a  management  philosophy  that  involves  participation  by 
everyone  in  an  organization  to  achieve  customer  satisfaction  through  continuous 
improvement.  TQM  focuses  on  error  prevention  and  the  elimination  of  waste  and  stresses 
building  quality  into  all  of  the  processes  of  an  organization,  whether  the  organization 
performs  one  or  a  combination  of  the  functions  of  defining,  building,  or  servicing  products 
for  its  customers.  Not  only  is  concurrent  engineering  consistent  with  the  Total  Quality 
Management  (TQM)  philosophy  and  way  of  doing  business,  but  in  the  authors'  view, 
concurrent  engineering  is  TQM  applied  to  the  engineering,  or  product  development, 
process. 

A  universal  element  in  the  practice  of  concurrent  engineering  and  TQM  is  the 
problem  solving  team  that  participates  in  regular,  formal  meetings.  The  multifunctional 
concurrent  engineering  team  engages  in  the  fundamental  problem  solving  process  of 
product  and  process  definition.  Although  higher  overall  productivity  has  been  shown  to 
result  from  multifunction  team  problem  solving  in  product  and  process  definition  (Winner, 
et  al.  1988),  initial  productivity  loss  is  often  associated  group  problem  solving.  This 
paper  presents  the  organizational  structures  and  management  practices  used  by  companies 
in  their  implementation  of  concurrent  engineering  and  focuses  or.  the  organization, 
management  practices,  and  support  used  to  minimize  the  inefficiency  often  associated  with 
meetings.  The  authors  then  present  technology  resources  that  could  be  used  to  support  the 
human  interaction  in  the  team  meetings.  These  technology  resources  are  intended  for 
organizations  practicing  concurrent  engineering  to  derive  the  benefits  of  group  work  while 
minimizing  the  productivity  loss  often  associated  with  group  work. 

A.  APPROACH 

To  provide  the  reader  with  useful  examples  showing  how  concurrent  engineering 
teams  are  being  organized  and  managed  and  how  the  concurrent  engineering  team  meetings 
are  conducted  and  supported,  the  research  team  reviewed  the  literature,  attended  various 
conferences,  and  visited  several  defense  contractors.  The  literature  reviewed  for  this  study 
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is  complied  in  an  annotated  bibliography  as  Volume  II  of  this  paper.  The  companies  vicitcd 
during  this  study  were  McDonnell  Douglas  Helicopter  Company  in  Mesa,  Arizona; 
Northrop  Aircraft  Division  in  Hawthorne,  California,  Lockheed  Aeronautical  Systems 
Company  (LASC)  in  Burbank  California;  General  Dynamics  Land  Systems  (GDLS)  in 
Sterling  Heights,  M'chigan;  and  McDonnell  Douglas  Aircraft  Company  (McAir)  and 
McDonnell  Douglas  Missile  Systems  Company  (MDMSC)  in  St.  Louis,  Missouri.  Many 
of  the  statements  made  in  this  paper  derive  from  specific  lessons  learned  by  concurrent 
engineering  teams  at  the  different  companies.  Whenever  possible,  the  authois  attribute  the 
information  to  specific  organizations. 

B.  FINDINGS 

In  the  summer  of  1990,  the  French  Ministry  of  Defense  sent  a  delegation  to  this 
country  to  visit  various  defense  contractors  to  obtain  information  about  how  concurrent 
engineering  is  being  implemented.  One  of  the  members  of  the  delegation  remarked  that 
each  company  had  their  own  vision  of  what  concurrent  engineering  is  and  how  to 
implement  it.  He  seemed  surprised  at  this — that  there  wasn't  one  standard  way  that  all 
organizations  followed.  A  basic  finding  of  this  study  is  that  there  is  no  one  way  to  do 
concurrent  engineering,  or  even  a  best  way.  Concurrent  engineering  reflects  a  philosophy 
and  a  way  of  doing  business  that  is  consistent  with  Total  Quality  Management  (TQM). 
Once  an  organization  accepts  the  philosophy  behind  concurrent  engineering,  how  it  is 
actually  done  is  very  dependent  on  the  history  of  the  organization  and  its  existing  culture, 
tools,  and  procedures.  In  fact,  during  the  authors'  site  visits  to  the  various  companies 
involved  in  this  study,  it  became  evident  that  the  concurrent  engineering  program  in  a 
company  depends  largely  on  the  advocate  of  concurrent  engineering  in  the  company-the 
characteristics  of  the  program  seem  to  follow  the  character  of  the  concurrent  engineering 
manager. 

1 .  Organization  and  Management  of  Concurrent  Engineering  Teams 

The  success  of  each  concurrent  engineering  project  clearly  depends  on  the  ability  of 
the  team  members  to  work  together,  thus,  total  team  satisfaction  with  the  process  and  the 
resulting  product  and  process  definition  is  pivotal.  Achieving  consensus  among  members 
of  a  concurrent  engineering  team  means  arriving  at  a  product  and  process  definition  that 
every  member  accepts.  The  multifunctional  nature  of  the  teams  complicates  the  group 
dynamics  because  of  the  language  barriers,  perceptions  of  unequal  status,  and  general 
cultural  barriers  to  teamwork.  Once  consensus  is  achieved  among  the  team  members,  it  is 


essential  that  buy-in  is  achieved  from  the  team  sponsor  and  upper  managers.  Various 
organizational  structures  and  team  management  practices  exist  to  overcome  these  difficulties 
and  accomplish  the  concurrent  engineering  team  approach  to  product  and  process 
definition.  The  key  element  of  all  of  the  methods  used,  however,  is  maintaining  open 
communication  during  the  process.  All  companies  stressed  the  importance  of  clear,  concise 
statements  of  the  team's  mission,  goals,  resources,  and  constraints;  accurate  but  concise 
recording  of  the  team  activities  distributed  to  aJl  relevant  people  in  the  organization;  and 
ongoing  briefings  of  team  progress  to  other  stakeholders.  Collocation  of  the  team  members 
allows  them  to  communicate  on  a  daily  basis  and  to  gain  an  understanding  of  each  other's 
perspective. 

2.  Concurrent  Engineering  Team  Meetings 

Discipline  in  the  meetings  is  an  important  element  contributing  to  the  success  of 
concurrent  engineering  team  meetings  and,  thus,  of  the  team  itself.  Companies  emphasize 
that  meetings  cannot  be  held  just  to  have  meetings.  Meeting  activities  are  generally  strictly 
limited  to  the  agenda  items,  and  all  of  these  activities  have  a  deliverable  focus.  What  is  said 
during  the  meetings  is  strictly  recorded,  and  this  meeting  documentation  should  exist  for 
the  management  and  program  reviews  as  well  as  the  regular  meetings.  Additional  support 
people  generally  become  pan  of  the  team--the  facilitator  and  the  recorder.  The  facilitator 
has  expertise  in  group  dynamics  and  group  problem  solving  methods  and  concentrates  on 
the  process  of  the  team  meeting  rather  than  the  technical  content.  The  recorder  at  a  meeting 
is  the  scribe  who  records  the  minutes  of  the  meeting.  The  recorder  must  be  careful  not  to 
alter  the  meaning  of  any  team  member's  contribution  when  documenting  the  meeting.  The 
recorder,  like  the  facilitator,  must  be  a  neutral,  non-evaluating  servant  of  the  team  during 
the  meeting.  In  addition,  having  a  single  designated  room  for  all  of  the  team  meetings 
where  the  complete  schedule  and  process  diagrams  are  displayed  and  the  action  items  are 
posted,  helps  focus  the  team  members. 

3.  Computer  Support  for  Concurrent  Engineering  Team  Meetings 

Many  of  the  significant  improvements  attributed  to  concurrent  engineering  come 
from  changes  in  the  management  of  the  product  and  process  definition  activities  rather  than 
advances  in  computer  technology.  If  the  philosopny  and  principles  guiding  the  company’s 
behavior  are  wrong,  no  amount  of  effort  or  additional  resources,  including  automation,  will 
keep  the  company  competitive.  However,  computers  will  continue  to  have  a  significant 
role  in  all  types  of  work.  Improving  existing,  and  finding  new,  applications  of  computer 
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technology  will  certainly  become  part  of  most  organizations’  continuous  improvement 
activities.  A  growing  number  of  researchers  are  exploring  ways  to  combine 
communication,  computer,  decision,  and  group  process  technologies  and  methodologies  to 
support  meetings.  Proposed  methods  of  introducing  computer  support  for  meetings  can  be 
as  simple  as  computer-controlled  audiovisuals  or  the  use  of  software  designed  for  a  single 
user  (e.g.,  word  processing,  spreadsheets,  outline  processors)  or  as  complex  as  the  use  of 
elaborate  meeting  rooms  that  provide  a  computer  for  every  participant.  In  the  near  term 
concurrent  engineering  meeting  support  will  most  likely  be  through  software  designed  for 
single-users  being  employed  in  group  settings.  The  more  elaborate,  multiple  computer 
support  systems  warrant  further  research,  especially  in  recognition  of  their  demonstrated 
success  in  the  face-to-face  group  support  in  business  applications  and  their  potential  to 
support  physically  separated  teams.  A  key  requirement  for  any  computer  system  that 
supports  concurrent  engineering  meetings  is  that  it  integrates  efficiently  with  the  other 
computer  systems  that  support  the  concurrent  engineering  team  (e.g.,  Computer-Aided 
Design,  engineering  data  management). 
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I.  INTRODUCTION 


Concurrent  engineering  is  a  systematic  approach  to  the  integrated,  parallel 
development  of  products  and  their  related  manufacturing  and  support  processes  to  increase 
customer  satisfaction.  Not  only  is  it  consistent  with  the  Total  Quality  Management  (TQM) 
philosophy  and  way  of  doing  business,  but  in  the  authors'  view,  concurrent  engineering  is 
TQM  applied  to  the  engineering,  or  product  development,  process. 

A  universal  element  in  the  practice  of  concurrent  engineering  and  TQM  is  the 
multifunctional  problem  solving  team.  The  multifunctional  concurrent  engineering  team 
engages  in  the  fundamental  problem  solving  process  of  product  and  process  definition.  In 
general,  the  benefits  of  doing  team  work  are  as  follows  (Warfield,  1986): 

•  The  team  has  a  greater  sum  total  of  knowledge  and  information  to  apply  to  the 
problem  solution. 

•  The  diverse  experiences  and  viewpoints  of  multiple  participants  yield  a  greater 
number  of  approaches  to  the  problem  solution. 

•  Team  members  understand  and  support  more  strongly  a  solution  that  they  help 
to  determine. 

•  Participants  obtain  a  common,  clear  understanding  of  requirements, 
configuration,  and  data. 

Although  higher  overall  productivity  has  been  shown  to  result  from  multifunction  team 
problem  solving  in  product  and  process  definition  (Winner,  et  at.  1988),  initial  productivity 
loss  is  often  associated  gToup  problem  solving.  The  social  science  community  has 
identified  several  reasons  why  group  problem  solving  can  reduce  productivity  (Kraemer 
and  King,  1986;  Warfield,  1986;  Nadler,  1981;  Delbccq,  Van  de  Vcn,  and  Gustafson. 
1975).  Essentially,  they  are-- 

•  Information  loss  due  to  group  pressure  leading  to  conformity  of  thought 

Discussions  are  dominated  by  certain  individuals. 

Low-status  members  defer  to  high-status  members-dominant  individuals 
exercise  undue  sway,  provide  pressure  toward  compromise. 
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•  Information  distortion 

-  Miscommunication  among  members  is  common. 

-  Goal  of  solution  to  problem  may  be  replaced  with  secondary  goal  of 
winning  an  argument 

•  Ineffectual  decision  making  because  insufficient  time  is  spent  in  problem 
exploration  and  generation  of  alternatives. 

•  Inefficient  individual  activity  and  progress  due  to  incremental  changes  and  poor 
communication,  causing  confusion. 

Since  design  and  manufacturing  are  heavily  dependent  upon  computer  support, 
much  of  the  literature  and  many  of  the  activities  surrounding  concurrent  engineering  efforts 
focus  on  the  computer.  However,  in  defining  concurrent  engineering,  Nevins  and  Whitney 
(1989)  state-- 

By  integration  we  do  not  mean  to  imply  any  particular  implementation  or 
technology.  The  correct  role  of  computers  and  "computer  integration”  is 
unclear  at  this  point.  The  same  may  be  said  of  robots,  expert  systems,  and 
other  new  developments.  The  importance  of  human  relations  and 
interactions,  and  organizational  and  institutional  arrangements,  is  only  dimly 
perceived,  although  many  observers  are  convinced  that  these  issues  far 
outweigh  technology  in  forming  an  effectively  integrated  approach.  Yet  the 
demands  of  complex  products  and  processes  strongly  indicate  that 
technology  will  be  needed.  The  issue  is  to  design,  choose  technology,  and 
operate  human-machine  systems  wisely. 

This  paper  presents  many  of  the  human  integration  issues  associated  with  concurrent 
engineering,  including  how  concurrent  engineering  teams  arc  organized  and  managed,  and 
how  the  concurrent  engineering  team  meetings  are  conducted  and  supported.  Recognizing 
that  advanced  computer  tools  arc  the  enablers  for  concurrent  engineering  (McAfee  3990) 
and  not  the  foundation  of  it,  this  paper  also  presents  technology  resources  that  could  be 
used  to  support  the  human  interaction  in  the  team  meetings.  These  technology  resources 
are  intended  for  organizations  practicing  concurrent  engineering  to  derive  the  benefits  of 
group  work  while  minimizing  the  productivity  loss  associated  with  group  work. 

A.  BACKGROUND 

Unified  Life  Cycle  Engineering  (ULCE),  an  Air  Force  Project  Forecast  II  Research 
and  Development  program,  began  in  1987  with  the  goal  of  developing  an  engineering 
environment  in  which  the  quality  of  a  product  is  improved  by  integrating  the  early 
consideration  of  producibility  and  supportability  with  performance,  cost,  and  schedule. 
This  envisioned  environment  would  make  use  of  advanced  computing  technologies. 


A  research  team  at  the  Institute  for  Defense  Analyses  (IDA),  including  the  authors 
of  this  paper,  has  participated  in  ULCE  research  for  the  Air  Force  Human  Resources 
Laboratory  (AFHRL),  Logistics  and  Human  Factors  Division,  since  the  inception  of  the 
program.  In  investigating  the  various  techniques  that  industry  uses  to  evaluate 
producibility  and  supportability  during  the  early  phases  of  the  product  development 
process,  the  IDA  research  team  identified  a  trend  toward  concurrent  engineering.  In 
concurrent  engineering,  integration  is  accomplished  through  the  use  of  a  multifunctional 
product  development  team,  and  customer  satisfaction  is  assured  through  a  continual  focus 
on  the  customer's  needs. 

The  EDA  team  then  initiated  research  into  concurrent  engineering  and  the  use  of 
computers  to  support  group  problem  solving  to  determine  the  implications  to  the  ULCE 
program  of  the  new  approaches  to  product  development  and  the  use  of  computer  support 
for  multifunctional  team  problem  solving.  The  researchers  presented  the  results  of  this 
work  in  Computer-Aided  Group  Problem  Solving  for  Unified  Life  Cycle  Engineering 
(ULCE)  (Dierolf  and  Richter,  1989).  The  authors  recommended  that  the  ULCE  program 
btoaden  its  focus  to  include  research  in  computer-aided  group  problem  solving  to  enhance 
the  effectiveness  of  product  and  process  definition  teams.  To  support  the  recommendation, 
the  authors  included  a  survey  of  structured  group  problem  solving  practices  used  in 
industry  for  concurrent  engineering  and  a  review  of  computer-aided  group  problem  solving 
methodologies  and  technology.  They  found  only  limited  applications  of  computer-aided 
group  problem  solving  to  engineering  design.  A  notable  exception  that  apparently  had 
broad  application  was  the  Boothroyd  and  Dewhurst  Design  for  Assembly  (DFA) 
methodology,  which  many  companies  have  used  to  support  concurrent  engineering  teams. 
Based  on  this  finding,  the  research  team  hypothesized  that  the  conceptual  approach  of  DFA 
could  be  used  for  early  supportability  assessment  by  a  concurrent  engineering  team  that 
included  the  customer  (the  Air  Force).  Using  the  computer  support  of  the  Computer-Aided 
Life  Cycle  Engineering  (CALCE)  system  for  electronic  design,  the  team  developed  a 
methodology  for  balancing  the  use  of  redundant  parts  in  a  product  with  scheduled 
maintenance  visits  in  order  to  achieve  an  operational  faicire-frce  system  at  a  low  life  cycle 
cost  (LCC).  The  results  of  this  research  are  recorded  in  Computer  Support  for  Conducting 
Supportability  Trade-Off s  in  a  Team  Setting  (Cralley,  Dierolf,  and  Richter,  1990). 

Sometime  during  FY  1988-89,  the  ULCE  program  was  incorporau  J  into  the  Air 
Force  portion  of  the  Department  of  Defense  concurrent  engineering  efforts.  The  ULCE 
program  was  one  of  several  programs  that  worked  toward  integrating  life  cycle  factors  into 
the  early  design  phases  by  focusing  on  single  features,  known  as  the  ilities,  e.g.. 
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reliability,  maintainability,  supportability,  producibility.  This  approach  ultimately  led  to  the 
institutionalization  of  separate  terminology  and  analysis  methods  and  to  the  formation  of 
stovepipe  functional  organizations  in  industry  and  government  (Aeronautical  Systems 
Division  (ASD),  1990a).  As  stated  in  The  Pymatuning  Group  report  (1988),  "This  'single 
feature*  or  ’ility’  approach  has  unfortunately  been  conducive  to  separate,  non-interacting 
program  offices  and  separate  budget  line  items  in  the  DoD  acquisition  process  each  directed 
to  a  'single  feature  improvement’  objective.  In  addition,  it  has  J’d  to  a  cumbersome, 
sequential,  and  prohibitively  costly,  sub-optimized  procurement  process."  Concurrent 
engineering  offers  the  opportunity  to  escape  this  single  feature  mentality.  In  FY  1990,  IDA 
was  tasked  to  extend  the  previous  work  in  computer  support  for  concurrent  engineering 
teams  and  their  meetings.  This  paper  presents  the  results  of  that  task. 


B.  APPROACH 

The  authors  approached  this  research  with  a  problem-oriented  perspective.  Their 
first  objective  was,  in  general,  to  develop  a  clear  understanding  of  concurrent  engineering 
and,  more  specifically,  to  leam  how  concurrent  engineering  teams  are  organized,  managed, 
and  supported-both  overall  and  in  their  team  meetings.  While  all  descriptions  of 
concurrent  engineering  include  the  characteristic  of  the  multifunctional  team,  little  is  written 
about  how  these  teams  are  organized  and  managed.  There  is,  however,  much  information 
on  teams  and  team  meetings  in  the  TQM  and  business  management  literature.  The  IDA 
researchers  reviewed  this  literature  and  complied  an  annotated  bibliography,  which  is 
included  in  Volume  II  of  this  paper. 

To  obtain  information  on  how  industry  is  implementing  the  team  approach  in 
concurrent  engineering,  the  research  team  reviewed  the  literature,  attended  various 
conferences,  and  visited  several  defense  contractors:  McDonnell  Douglas  Helicopter 
Company  in  Mesa,  Arizona;  Northrop  Aircraft  Division  in  Hawthorne,  California, 
Lockheed  Aeronautical  Systems  Company  (LASC)  in  Burbank  California;  General 
Dynamics  Land  Systems  (GDLS)  in  Sterling  Heights,  Michigan;  and  McDonnell  Douglas 
Aircraft  Company  (McAir)  and  McDonnell  Douglas  Missile  Systems  Company  (MDMSC) 
in  St.  Louis,  Missouri.  Many  of  the  statements  made  in  this  paper  derive  from  specific 
lessons  learned  by  concurrent  engineering  teams  at  the  different  companies.  Whenever 
possible,  the  authors  attribute  the  information  to  specific  organizations. 
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C.  REPORT  OVERVIEW 

In  1989,  Dr.  Robert  Costello,  then  Undersecretary  of  Defense  (Acquisition),  wrote 
a  memorandum  (Costello,  1989)  endorsing  concurrent  engineering.  The  memo,  titled 
Concurrent  Engineering  -  A  Total  Quality  Management  (TQM )  Process ,  stated,  "This 
integrated  process,  i.e.,  concurrent  engineering,  resulted  from  each  of  the  firms  [studied  by 
the  DoD/Industry  Task  Force  on  Concurrent  Engineering]  having  practiced  TQM  principles 
to  redesign  their  own  engineering  processes."  Chapter  II  elaborates  on  the  relationship 
between  concurrent  engineering  and  TQM. 

Chapter  HI  presents  what  the  researchers  learned  about  the  organization  and 
management  of  concurrent  engineering  teams  and  their  meetings  from  their  review  of  the 
literature  and  visits  to  defense  contractors  with  concurrent  engineering  activities.  The 
companies  examined  for  this  research  each  organized  and  managed  their  concurrent 
engineering  teams  differently,  and  the  authors  endorse  the  view  that  there  is  no  one  right 
way  to  do  concurrent  engineering.  The  information  in  Chapter  HI  can  give  useful  insights 
to  a  company  implementing  concurrent  engineering,  but  each  organization  must  adopt  the 
team  management  principles  with  respect  to  its  own  culture. 

Chapter  IV  describes  how  the  computer  can  improve  the  productivity  of  concurrent 
engineering  teams  when  they  are  meeting  face-to-face.  This  particular  use  of  technology 
has  not  previously  been  addressed  by  the  concurrent  engineering  research  community. 

Chapter  V  concludes  the  report  with  a  summary  of  the  findings  and  research 
recommendations. 

Volume  II  of  this  paper  contains  annotated  bibliographies  of  the  literature  reviewed 
for  this  study.  The  subjects  are  TQM,  concurrent  engineering,  Quality  Function 
Deployment  (QFD),  and  group  problem  solving. 
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II.  CONCURRENT  ENGINEERING  AND  TOTAL 
QUALITY  MANAGEMENT 


In  1988,  the  Office  of  the  Assistant  Secretary  of  Defense  for  Production  and 
Logistics  sponsored  two  studies  that  examined  how  concurrent  engineering  might  be 
applied  to  weapons  system  acquisition.  IDA  performed  one  of  these  studies  and  published 
The  Role  of  Concurrent  Engineering  in  Weapons  System  Acquisition  (Winner,  et  ai, 
1988).  Winner,  et  al.,  defined  concurrent  engineering  as  follows: 

A  systematic  approach  to  the  integrated,  concurrent  design  of  products  and 
their  related  processes,  including  manufacture  and  support.  This  approach 
is  intended  to  cause  the  developers,  from  the  outset,  to  consider  all  elements 
of  the  product  life  cycle  from  conception  through  disposal,  including 
quality,  cost,  schedule  and  user  requirements. 

The  other  study  was  conducted  by  The  Pymatuning  Group.  Their  report.  Industrial 
Insights  on  the  DoD  Concurrent  Engineering  Program  (1989),  defines  concurrent 
engineering  as~ 

. .  the  set  of  methods,  techniques  and  practices  that: 

•  Cause  significant  consideration  within  the  design  phases  of  factors 
from  later  in  the  life  cycle, 

•  Produce,  along  with  the  product  design,  the  design  of  processes  to  be 
employed  later  in  the  life  of  the  product, 

•  Facilitate  the  reduction  of  the  time  required  to  translate  designs  into  the 
fielded  products,  and 

•  Enhance  the  ability  of  products  to  satisfy  users'  expectations  and 
needs." 

An  essential  element  of  concurrent  engineering  is  good  design  engineering 
management ..." 

These  definitions  identify  desirable  results  of  concurrent  engineering.  These 
definitions  do  not,  however,  emphasize  the  relationship  between  concurrent  engineering 
and  TQM-a  relationship  that  is  evident  within  the  reports.  The  authors  of  the  IDA  report 
found  that  improving  qua'ity  was  a  recurring  theme  among  the  companies  visited  for  their 
industry  case  studies  (Winner,  et  ai,  1988).  They  wrote: 


Without  the  emphasis  on  quality  that  characterizes  TQM  [Total  Quality 
Management],  concurrent  engineering  will  not  achieve  its  goals.  In  fact, 
every  company  visited  during  this  study  has  either  begun  to  implement  its 
own  TQM  program  or  has  developed  an  in-house  quality  improvement 
program  that  is  basically  equivalent 

The  Pymatuning  study  also  states,  "Concurrent  Engineering  practices  are  an  integral  part 
of  quality  management  and  quality  engineering."  Another  recent  IDA  report  (Pennell  and 
Akin,  1990)  states- 

Of  the  many  methods  associated  with  concurrent  engineering,  some  of  the 
most  striking  come  from  the  quality  community.  In  gathering  information 
for  this  report,  the  authors  found  that  quality  initiatives  are  inseparable  from 
concurrent  engineering. 

TQM  is  a  management  philosophy  that  involves  participation  by  everyone  in  an 
organization  to  achieve  customer  satisfaction  through  continuous  improvement.  TQM 
focuses  on  error  prevention  and  the  elimination  of  waste.  To  be  successful,  it  must  not  be 
viewed  as  a  program  with  a  beginning  and  an  end  but  rather  as  a  new  way  of  doing 
business.  Organizations  must  practice  TQM  much  like  race  car  builders  practice  their 
profession— continually  improving  their  methods  and  adapting  to  change.  These  are  all 
desirable  attributes  for  an  organization  practicing  concurrent  engineering  as  well.  TQM 
stresses  building  quality  into  all  of  the  processes  of  an  organization,  whether  the 
organization  performs  one  or  a  combination  of  the  functions  of  defining,  building,  or 
servicing  products  for  its  customers. 

This  chapter  expands  on  the  relationship  between  concurrent  engineering  and  TQM 
by  showing  that  the  fundamental  characteristics  of  organizations  practicing  TQM  are 
consistent  with  and  desirable  for  organizations  wanting  to  implement  concurrent 
engineering.  Commonly  described  characteristics  of  organizations  subscribing  to  the  TQM 
philosophy  include: 

•  A  process  orientation  and  a  commitment  to  continual  improvement 

•  A  focus  on  customer  satisfaction. 

•  A  scientific  approach  to  problem  solving. 

•  An  emphasis  on  human  resources  and  teamwork,  including  continued 
education  and  training. 

•  Strong  management  commitment  and  leadership. 

The  following  sections  describe  these  characteristics,  elaborating  on  TQM  applied  to 
product  and  process  definition  (concurrent  engineering). 
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A.  A  PROCESS  ORIENTATION  AND  A  COMMITMENT  TO  CONTINUAL 
IMPROVEMENT 

A  fundamental  concept  of  the  TQM  philosophy  is  acknowledging  the  process.  Any 
organization,  whether  a  manufacturing  firm,  a  service  or  research  organization,  or  a 
consulting  firm,  accomplishes  its  mission  via  processes.  A  process  is  an  orderly  set  of 
tasks  that  results  in  a  particular  outcome  (e.g.,  service,  product,  information).  Each 
process  has  suppliers  that  provide  the  process  resources  and  customers  that  receive  the 
process  results.  The  people  responsible  for  the  tasks  within  the  process  are  the  process 
owners.  Process  owners  are  both  customers  (of  their  suppliers)  and  suppliers  (to  their 
customers).  A  basic  TQM  tenet  is  that  true  increases  in  productivity  come  from  improving 
the  processes,  not  controlling  and  managing  according  to  the  results  of  the  processes. 
Furthermore,  by  improving  the  work  processes,  flexibility  can  be  built  into  an 
organization — flexibility  needed  to  cope  with  rapid  change  caused  by  increasing  complexity 
and  changing  technology. 

Continual  process  improvement  is  the  progressive  response  of  an  organization  to 
the  continual  change  in  the  business  and  technological  environments.  All  processes  can 
and  should  fc  :  subject  to  continual  improvement  efforts.  A  series  of  small  incremental 
improvements  over  time  add  up  to  major  gains  in  process  efficiency  and  effectiveness  and 
assures  that  the  organization  keeps  pace  with  the  changing  environment.  Everyone  in  an 
organization  must  recognize  that  any  process  can  be  improved,  even  if  the  results  of  the 
process  are  judged  to  be  adequate  by  current  standards.  A  climate  of  continual 
improvement  comes  when  each  worker  questions  the  standards  and  asks  “Is  there  a  better 
way?” 

Concurrent  engineering  involves  the  definition  of  the  manufacturing  and  support 
processes  in  parallel  with  the  product  definition.  The  implementation  of  concurrent 
engineering  is  an  improvement  of  both  the  product  and  process  definition  processes. 
Continuous  improvement  of  the  design  process  is  explicitly  cited  as  one  of  "The  Ten+One 
Commandments  of  Concurrent  Engineering"  in  a  recent  CALS  Report  (1990).  One  of  the 
first  steps  in  improving  the  process  is  understanding  it.  All  of  the  companies  visited  during 
this  study  put  considerable  effort  into  documenting  their  product  development  process  in 
order  to  analyze  it  and  find  ways  to  improve  it.  One  of  the  fundamental  improvements 
observed  in  most  companies  is  the  adoption  of  a  phased,  parallel  release  of  the  product  and 
manufacturing  process  descriptions.  Early,  incomplete  (tentative  and  fragmentary) 
information  is  allowed  to  move  between  the  defmers  of  the  product  and  the  definers  of  the 
manufacturing  processes  instead  of  waiting  for  the  official  transmittal  of  a  formal  drawing 


of  the  complete  product  design.  In  this  way  unworkable  alternatives  are  eliminated  early  in 
the  process,  and  a  flexible  manufacturing  process  that  can  respond  to  changes  quickly  is 
developed  (Hayes,  Wheelwright,  and  Clark,  1988). 

B .  A  FOCUS  ON  CUSTOMER  SATISFACTION 

The  primary  goal  of  TQM  is  satisfied  customers.  Two  types  of  customers  are 
defined:  external  customers  that  purchase  the  goods  or  services  of  the  organization,  and 
internal  customers  who  receive  the  results  of  other  employees'  work.  For  example,  the 
manufacturing  division  of  a  company  is  considered  an  internal  customer  of  the  product 
definition  group.  Customers  are  satisfied  with  products  that  meet  their  quality  standards 
and  are  delivered  when  they  need  them.  External  customers  also  require  a  price  they 
believe  is  fair.  The  key  point  is  that  adequate  quality,  reasonable  cost,  and  acceptable 
delivery  date  are  defined  by  the  customer— suppliers  must  understand  their  customer's 
needs. 

Concurrent  engineering  has  4  customers:  the  end  user  of  the  product  being 
developed,  the  manufacturer  of  the  product,  the  service  organization  that  will  support  the 
product,  and  the  organization  that  will  dispose  of  the  product.  The  manufacturing  and 
support  planners  (the  internal  customers)  have  representatives  on  the  concurrent 
engineering  team  to  assure  that  the  needs  of  the  manufacturing  and  support  organizations 
are  met.  The  concurrent  engineering  team  learns  the  end  user's  need  at  the  start  of  product 
and  process  definition  by  the  generation  of  requirements.  These  requirements  must  be 
tracked  throughout  the  product  and  process  definition  to  assure  that  the  needs  of  the 
external  customer  are  met.  Ideally,  the  customer  is  a  member  of  the  team.  "Since 
customers  often  do  not  understand  the  subtleties  of  their  needs  and  even  more  frequently 
the  limits  of  technology,  realistic  product  development  becomes  a  problem  solving  process 
among  multiple  customers  and  multiple  functional  experts  working  as  a  team"  (ASD, 
1990a). 

As  an  example,  the  General  Dynamics  Land  Systems  (GDLS)  Ml  A2  (Abrams  tank) 
concurrent  engineering  team  stresses  the  importance  of  their  customers'  involvement.  A 
Captain  and  a  Sergeant,  responsible  to  the  Commanding  General  at  Fort  Knox,  are  located 
on  site  with  the  concurrent  engineering  team  and  participate  daily  in  the  team  activities. 
Requirements  definition  for  the  M1A2  was  a  team  process  with  the  Army,  and  over  100 
people  from  the  Army  participated  in  a  system  design  review. 


C.  A  SCIENTIFIC  APPROACH  TO  PROBLEM  SOLVING 


TQM  promotes  the  scientific  approach  to  problem  solving,  which  is  a  systematic 
way  to  understand,  learn  about,  and  improve  processes.  "It  means  agreeing  to  make 
decisions  based  on  data  rather  than  hunches,  to  look  for  root  causes  of  problems  rather  than 
react  to  superficial  symptoms,  to  seek  permanent  solutions  rather  than  rely  on  quick  fixes" 
(Scholtes,  1988).  Practioners  of  TQM  use  sophisticated  statistical  and  experimental 
methods  as  well  as  some  basic  techniques  for  planning  and  tracking  the  processes.  These 
techniques  emphasize  graphics  to  assist  the  team  in  visualizing  the  process. 

In  concurrent  engineering,  such  an  approach  is  essential  to  thoroughly  understand 
the  interrelationships  among  the  defining,  building,  and  supporting  phases  of  a  product's 
life  cycle.  Such  techniques  as  experimental  design,  simulation  modelling,  and 
mathematical  analyses  seek  to  provide  a  deeper  understanding  of  these  relationships  and 
determine  root  cause  effects.  For  example,  reliability  engineers  in  the  traditional,  sequential 
design  process  performed  analyses  on  a  proposed  product  design  to  determine  whether  the 
design  met  the  reliability  specifications.  The  result  of  the  analyses  was  typically,  a  yes  or 
no  answer.  Under  concurrent  engineering,  the  reliability  engineers  must  learn  to  take  a 
different  approach  to  their  task  and  solve  a  different  type  of  problem.  They  need  to 
determine  the  root  causes  of  predicted  failures  and  suggest  changes  in  the  design  that  will 
lead  to  a  more  reliable  product. 

D.  AN  EMPHASIS  ON  HUMAN  RESOURCES  AND  TEAMWORK, 
INCLUDING  CONTINUED  EDUCATION  AND  TRAINING 

A  fundamental  tenet  of  TQM  is  that  an  organization’s  most  valuable  resource  is  its 
people.  In  an  organization  embracing  TQM,  everyone  contributes  to  process  improvement. 
An  atmosphere  of  mutual  trust  and  respect  exists  in  which  employees  are  motivated  to 
identify  improvement  opportunities  and  to  participate  in  analyzing  and  determining 
improvement  strategies.  Teams  of  employees  are  often  used  for  improvement  activities 
since  teams  bring  a  greater  sum  knowledge  to  bear  on  the  problem,  provide  mutual  support 
for  their  members,  and  establish  informal  communication  channels  throughout  the 
organization. 

A  multifunctional  team,  consisting  of  specialists  from  all  relevant  departments  of  the 
corporation  (e.g.,  engineering,  manufacturing,  finance,  marketing),  is  an  essential  element 
of  concurrent  engineering.  Most  of  the  literature  on  concurrent  engineering  emphasizes  that 
the  external  suppliers  or  subcontractors  as  well  as  customers  or  end  users  should  be  active 
members  of  the  concurrent  engineering  team. 
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The  major  benefit  of  this  teamwork  is  enhanced  communication  among  the  product 
developers,  their  suppliers,  and  their  customers.  An  atmosphere  in  which  team  members 
can  "work  as  equals  in  a  climate  of  trust  and  ownership  to  incrementally  refine  the 
definition  of  the  product  and  its  manufacturing  and  support  capabilities"  must  be  cultivated 
(ASD,  1990a).  As  Hayes,  Wheelright  and  Clark  warn  in  their  book.  Dynamic 
Manufacturing  (Hayes,  Wheelright  and  Clark,  1988), 

Many  companies  see  technology  as  the  answer  to  their  competitiveness 
problems.  The  new  technologies,  however,  demand  more--not  less-of 
workers  and  managers  in  order  to  achieve  their  potential.  Somewhat 
paradoxically,  as  processes  become  more  sophisticated  and  more 
automated,  success  is  becoming  less  a  matter  of  substituting  technology  for 
people,  if  it  ever  was.  Instead,  human  skills  must  be  developed 
simultaneously  with  computer  software  and  equipment  hardware,  and 
managed  in  such  a  way  that  they  reinforce  each  other. 

A  cornerstone  of  this  emphasis  on  human  resources  and  teamwork  is  training  in  the 
underlying  philosophy  of  continual  improvement,  the  tools  and  techniques  of  the  scientific 
approach  to  problem  solving,  and  the  skills  required  to  work  effectively  in  a  team  setting. 
In  many  organizations,  part  of  the  training  program  is  job  rotation.  This  approach  not  only 
provides  a  more  qualified,  robust  work  force,  but  engenders  unity  within  the  work  force  as 
workers  gain  an  understanding  of  their  co-workers'  duties  and  responsibilities.  Training  in 
the  scientific  approach  to  problem  solving  includes  training  in  measurement  and  statistics. 
Training  in  problem  solving  enables  the  work  force  to  identify,  analyze,  and  select 
improvement  opportunities  and  strategies. 

All  of  the  above  training  is  required  for  concurrent  engineering,  but  because  of  the 
multifunctional  nature  of  the  concurrent  engineering  teams,  cross-functional  training  of 
team  members  becomes  especially  important.  Because  of  the  functional  divisions  in 
traditional  organizations  (e.g.,  design,  reliability,  maintainability,  quality  assurance, 
manufacturing),  each  functional  group  has  developed  its  own  language  (both  technical 
terms  and  jargon)  over  time.  These  specialty  languages  make  cross-functional 
communication  very  difficult.  Learning  about  functions  other  than  their  own  enables  the 
team  members  to  communicate  effectively.  If  team  members  cannot  cross-train  through 
actual  job  rotation,  they  must  receive  training  to  acquaint  them  with  the  functions  performed 
and  the  technical  terms  used  by  the  other  team  members.  Teamwork  is  enhanced  when  the 
language  barriers  between  the  functional  groups  are  overcome. 

One  of  the  teams  that  shared  their  lessons  learned  for  this  research  project  found 
that  a  lack  of  training  in  group  dynamics  led  to  varied  participation  and  unequal 
understanding  of  responsibilities  among  team  members.  One  of  their  lessons  learned  is  that 
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the  degree  of  participation  of  a  team  member  is  based  on  their  innate  group  interaction  skills 
or  on  skills  learned  either  in  organizations  such  as  Toastmasters  International  or  in  college. 
This  team  also  found  that  discussing  what  a  team  is  and  what  it  is  not  at  the  first  or  second 
meeting  was  helpful,  and  recommended  TQM  training  for  all  team  members  before 
concurrent  engineering  teams  begin  work  (Little,  1990). 

Another  of  the  concurrent  engineering  teams  consulted  in  this  study  received  no 
special  training  in  team  work  for  the  concurrent  engineering  project,  although  many  of  the 
team  members  received  some  team  training  during  previous  participative  management 
initiatives,  e.g..  Quality  Circles,  in  the  organization.  The  organization  did,  however, 
institute  extensive  cross-training  and  job  rotation  and  trained  team  members  from  all 
disciplines  in  corporate  standard  design  practices  ard  the  use  of  the  corporate  Computer- 
Aided  Design  (CAD)  system  (Stevens,  1990). 

E.  STRONG  MANAGEMENT  COMMITMENT  AND  LEADERSHIP 

It  is  the  role  of  management  to  create  and  foster  the  organizational  culture  for  TQM 
that  allows  people  to  focus  on  quality  and  continual  improvement  Managers  must  become 
coaches  whose  purpose  is  to  provide  workers  the  requisite  resources  to  continually 
improve  their  assigned  job.  Management  must  set  the  strategic  vision  and  goals  for  the 
organization  so  that  the  entire  organization,  down  to  the  individual  worker,  can  relate  their 
daily  efforts  to  the  organization's  mission. 

Whether  organizational  change  is  slight  or  significant,  management  commitment  to 
concurrent  engineering  is  essential.  Changes  at  McDonnell  Douglas,  for  example,  began 
with  an  executive  commitment  for  research  followed  by  an  executive  commitment  to 
change.  The  levels  of  management  were  reduced  from  nine  to  five.  Often  the 
implementation  of  concurrent  engineering  begins  with  a  specific  project  as  a  test  bed,  but 
the  project  needs  the  sponsorship  of  a  vice  president  or  general  manager.  The  case  studies 
in  the  IDA  report  on  concurrent  engineering  (Winner,  1988;  Appendix  A)  all  emphasized 
the  need  for  strong  management  involvement  for  the  success  of  the  concurrent  engineering 
efforts. 

It  is  up  to  management  to  create  an  organizational  structure  and  resulting 
organizational  climate  in  which  a  TQM  approach  to  product  and  process  definition  can 
survive  and  flourish.  For  concurrent  engineering  to  work  effectively,  there  must  be 
teamwork  among  the  product  and  process  definition  team  members,  open  lines  of 
communication  among  the  team  and  throughout  the  organization,  and  commitment  on  the 
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part  of  management  to  provide  adequate  resources  (time  and  money).  The  following 
chapter  describes  some  team  organization  and  management  practices  to  accomplish  these 
goals. 
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III.  ORGANIZATION  AND  MANAGEMENT  OF 
CONCURRENT  ENGINEERING  TEAMS 

This  chapter  presents  many  of  the  issues  that  must  be  considered  for  the  efficient 
functioning  of  concurrent  engineering  teams.  These  issues  and  ideas  pertain  not  only  to 
concurrent  engineering  teams  but  also  to  many  different  types  of  teams  with  slight 
variations.  Generally,  there  are  many  attributes  that  may  vary  among  the  different  types  of 
teams.  These  include-- 

•  The  capabilities  and  status  of  the  members. 

•  The  size  of  the  team. 

•  The  homogeneity  of  the  members. 

•  The  transient  or  pernraient  nature  of  the  team. 

•  Tne  complexity  of  the  problem  the  team  has  to  solve. 

•  The  time  constraints  for  determining  the  solution. 

Problem  solving  in  product  and  process  definition  of  complex  systems  goes  beyond 
decision  making-it  includes  defining  the  problem,  generating  alternative  solutions, 
evaluating  alternatives,  selecting  alternatives,  and  implementing  the  solution.  The  problems 
are  multileveled,  multidimensional,  and  mulddisciplinary--all  of  the  information  required  to 
form  a  solution  may  not  be  available,  and  the  available  information  may  be  based  on 
judgment  and  experience.  The  design  of  complex  systems  involves  human  interaction 
among  engineers  with  various  backgrounds  and  from  various  disciplines.  When  multiple 
measures  of  merit  forjudging  the  level  of  acceptability  of  a  design  exist,  all  may  not  be 
equally  important  to  the  functionality  of  the  design,  but  certainly  all  are  not  equally 
important  to  each  individual  member  on  the  concurrent  engineering  team  (Mistrce  and 
Muster,  1988;  Muster  and  Mistree,  1988). 

The  success  of  each  concurrent  engineering  project  clearly  depends  on  the  ability  of 
the  team  members  to  work  together,  thus,  total  team  satisfaction  with  the  process  and  the 
resulting  product  and  process  definition  is  pivotal.  Achieving  consensus  among  members 
of  a  concurrent  engineering  team  means  arriving  at  a  product  and  process  definition  that 
every  member  accepts  (Doyle  and  Strauss,  1982).  Each  member  may  not  think  a  design  is 
the  absolute  best  attainable,  but  in  agreeing  to  a  particular  design,  each  member  must 


believe  that  it  is  a  good  design  and  that  all  essential  design  elements  have  been  included. 
Having  all  members  satisfied  with  the  design  ensures  ownership  and  responsibility  among 
team  members.  Once  consensus  is  achieved  among  the  team  members,  it  is  essential  that 
buy-in  is  achieved  from  the  team  sponsor  and  upper  managers.  The  preferred  method  is  by 
maintaining  open  communication  during  the  process  to  prevent  management  objections 
during  the  implementation  phase. 

The  multifunctional  nature  of  the  teams  complicates  the  group  dynamics  because  of 
the  language  barriers,  perceptions  of  unequal  status,  and  general  cultural  barriers  to 
teamwork.  The  GDLS  Ml  A2  concurrent  engineering  team  has  developed  a  list  of  specific 
obstacles  that  challenge  management  in  promoting  effective  product  and  process  definition 
(Tierney  1990): 

•  Engineering  division  members  see  themselves  as  creative  individuals  who  do 
not  want  that  creativity  restricted  by  having  to  accommodate  all  functional 
concerns. 

•  Manufacturing  division  members  have  to  satisfy  customers’  current  orders  and 
maintain  stability. 

•  Rigid,  functionally  dominated  organizational  structures  exist. 

•  Everyone's  organizational  base  becomes  the  center  of  their  universe. 

Management  must  overcome  these  obstacles  if  the  definition  process  is  to  work  effectively. 
Various  methods  and  management  practices  exist  to  overcome  these  difficulties  and 
accomplish  the  concurrent  engineering  approach  to  product  and  process  definition.  This 
chapter  describes  some  of  the  various  organizational  and  management  strategies  industry  is 
practicing  to  fully  utilize  teamwork  in  product  and  process  definition. 

A.  CORPORATE  ORGANIZATIONAL  STRUCTURE 

As  products  became  so  complex  that  a  single  designer  or  even  a  small  group  of 
designers  could  no  longer  efficiently  design  them,  many  large  companies  chose  to  organize 
around  specific  functions  and  accomplish  projects  using  a  matrix  type  of  structure. 
Professor  John  Mec  defined  a  matrix  organization  in  1964:  "A  matrix  type  of  organization 
is  built  around  specific  projects.  A  manager  is  given  the  authority,  responsibility,  and 
accountability  for  the  completion  of  the  project  in  accordance  with  the  time,  cost,  quality, 
and  quantity  provisions  in  the  project  contract.  The  line  organization  develops  from  the 
project  and  leaves  the  previous  line  functions  in  a  support  relationship  to  the  project  line 
organization." 
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Under  this  form  of  management,  the  personnel  in  an  organization  are  aligned  by 
functional  groups,  comprising  the  vertical  columns  of  the  matrix,  and  projects  are 
accomplished  by  assigning  one  or  more  individuals  from  each  functional  group  to  each 
project,  comprising  the  horizontal  rows  of  the  matrix.  One  problem  with  this  type  of 
organization  is  that  the  project  engineer,  who  has  to  rely  on  team  members  from  the 
different  functional  groups,  typically  has  little  authority  over  those  people.  Team  members 
are  loyal  to  their  functional  divisions  where  they  are  evaluated,  compensated,  and 
considered  for  promotion.  This  functional  division  separates  the  specialty  engineers  from 
each  other  as  well  as  from  the  designers--the  most  notable  separation  occurring  between  the 
engineers  and  the  manufacturing  personnel.  To  alleviate  the  difficu’ties  associated  with  the 
traditional  corporate  organization,  engineering  companies  are  considering  various 
organization  models  from  diverse  fields.  Northrop  Aircraft  Division  (NAD)  has  studied  the 
organizational  design  literature  and  based  on  a  widely  shared  organizational  model 
(Galbraith,  1977;  Beckhard  and  Harris,  1987;  LawTence  and  Lorsch,  1967;  Hanna,  1988) 
has  developed  strawman  guiding  principles  for  the  teams.  These  guiding  principles 
covered  basic  strategies  and  systems  to  be  used  by  the  concurrent  engineering  teams  to 
design  their  operating  processes. 

Some  companies  have  decided  that  functional  alignment  is  not  the  most  conducive 
structure  for  the  product  and  process  definition  team  effort  and  are  experimenting  with 
different  organizational  structures  for  implementing  the  concurrent  engineering  approach  to 
product  development  using  a  multifunctional  team.  McDonnell  Douglas  has  essentially 
shifted  the  matrix  organizational  chart  90  degrees  to  align  their  organization  by  product 
lines  ar.d  allow  the  product  line  managers  to  evaluate  employees.  McDonnell  Douglas  has 
also  established  a  support  division  (a  vertical  column  alongside  the  product  lines)  that  is 
responsible  for  providing  the  horizontal  ties  of  the  corporate-wide  processes  and  improving 
them.  Members  of  this  division  are  paid  entirely  out  of  overhead.  The  horizontal 
integration  is  related  to  process,  the  vertical  integration  is  related  to  product. 

Other  companies  have  found  that  functional  alignment  does  not  hamper  their 
concurrent  engineering  efforts  (Huthwaite,  1990).  In  fact,  functional  alignment  offers 
advantages  when  subsystems  or  components  are  not  unique  across  product  lines,  such  as 
when  product  compatibility  or  parts  commonality  is  beneficial  (Hayes,  Wheelwright,  and 
Clark,  1988).  Huthwaite  calls  implementing  concurrent  engineering  teams  within  the 
traditional  corporate  structure  "Teamwork  within  the  Tradition."  Multifunctional  project 
engineering  teams  arc  formed  of  people  from  the  various  functional  groups,  such  as 
manufacturing,  reliability,  design,  and  quality  engineers,  augmented  with  purchasing 
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personnel,  suppliers,  and  users.  These  teams  direct  and  integrate  all  technical  aspects  of 
the  design  and  development  process  of  a  product  and  in  general  have  more  responsibility, 
authority,  and  accountability  than  project  teams  in  the  past.  More  authority  also  rests  in  the 
hands  of  the  project  leader.  Team  members  report  to  the  project  leader,  who  reports  to 
upper  management.  Obviously  this  type  of  arrangement  may  threaten  some  functional 
managers,  who  see  it  as  a  usurpation  of  their  authority.  This  is  one  of  the  cultural  barriers 
that  must  be  overcome  for  concurrent  engineering  teams  to  be  successful  in  traditional 
organizations. 

GDLS  is  functionally  aligned,  and  its  approach  to  concurrent  engineering  for  the 
M1A2  appears  to  be  very  successful.  The  concurrent  engineering  team  functions  as  a 
systems  integration  team  whose  individual  members  are  also  members  of  the  product  and 
process  definition  teams.  In  implementation,  the  Chief  Engineer,  responsible  for  the 
Technical  Data  Package,  and  the  concurrent  engineering  lead  of  the  GDLS  M1A2  project 
both  report  to  the  same  level  of  management.  One  of  the  lessons  learned  by  this  team  was 
that  people  often  encumber  the  concurrent  engineering  process  with  the  excuse  "there’s  not 
enough  time  to  do  my  function  and  share  in  concurrent  engineering."  Organizational 
policies  and  practices  (including  those  for  performance  review  and  promotion)  must  foster 
the  attitude  that  concurrent  engineering  and  TQM  are  everyone’s  job. 

B  .  TEAMS  OF  TEAMS 

A  general  rule  for  effective  group  interaction  is  that  the  group’s  size  not  exceed  8-12 
members.  However,  the  development  of  a  complex  product  can  require  hundreds  of 
people  from  various  functional  groups  in  an  organization.  The  complete  concurrent 
engineering  team  performs,  therefore,  as  a  team  of  teams.  The  use  of  the  word  team  here 
has  more  to  do  with  a  way  of  thinking  about  a  problem  than  the  size  of  the  group.  "A  team 
consists  of  professionals  who  operate  from  a  shared  agenda  and  a  common  view  of  their 
assignment"  (Heany,  1989). 

The  team  of  teams  is  usually  a  hierarchy  of  teams  that  follows  the  decomposition  of 
the  physical  product  into  zones  or  subsystems  for  the  product  and  process  definition. 
Aligning  teams  according  to  the  work  breakdown  structure  (WBS)  has  been  suggested 
(Meyer,  1990).  The  term  hierarchy  here  does  not  apply  to  the  status  of  the  teams  or  team 
members  but  rather  to  the  relationships  among  the  teams  and  how  these  relationships 
correspond  to  product  and  process  definition  responsibility.  Communication  can  be 
maintained  among  teams  by  placing  a  member  (usually  the  team  leader)  from  a  lower  level 
team  on  a  team  at  the  next  highest  level.  The  high-level  team  resembles  a  systems 
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engineering  team  that  defines  the  integration  of  the  results  of  the  other  teams.  ’"Systems 
engineering  in  this  case  is  not  intended  to  be  a  'specialty'  itself.  Instead,  it  provides  the 
framework  to  manage  integration  of  the  development  process  of  the  product  and  its 
manufacturing  and  support  processes"  (ASD,  1990a). 

There  is  usually  at  least  one  team  for  each  node  on  the  decomposition  of  the 
product.  If  the  product  and  process  definition  of  the  subassembly  or  zone  requires  more 
than  a  dozen  people,  the  teams  are  further  divided  by  discipline  or  technology  (e.g., 
composites,  electrical,  avionics).  The  decomposition  occurs  until  the  subsystems  can  be 
defined  by  a  manageable  group  (8  to  12  people).  For  example,  the  McAir  Integrated 
Product  Teams  (IPT)  are  organized  by  disciplines  within  the  product  center.  The  theory 
behind  organizing  the  teams  along  discipline  or  technology  lines  either  within  the  product 
center  or  subsystem  is  that  grouping  people  by  discipline  is  a  way  to  break  the  language 
barrier  so  often  encountered  when  people  who  have  traditionally  performed  different 
functions  try  to  communicate.  Most  members  of  the  same  discipline  speak  the  same 
language,  regardless  of  their  function.  For  example,  mechanical  engineers,  whether  from 
the  engineering,  manufacturing,  or  support  group,  will  understand  most  of  one  another's 
technical  terms  because  of  common  education. 

McDonnell  Douglas  Missile  Systems  Company  (MDMSC)  uses  seven  concurrent 
engineering  teams  for  the  Advanced  Harpoon  Block  ID  project:  four  product  development 
teams  (Missile,  Cannister,  Test  Articles,  and  Ground  Support  Equipment)  and  three 
process  teams  (Machine  Parts,  Tooling,  and  Procurement).  A  Steering  Committee  consists 
of  the  seven  team  leaders  and  some  specialists.  The  Steering  Committee  meets  to  discuss 
the  teams’  activities  and  any  problems,  and  is  responsible  for  the  concurrent  engineering 
procedures  and  cross-communication  among  the  teams. 

Lockheed  Aeronautical  Systems  Company  uses  a  variety  of  team  organizational 
structures,  depending  on  the  size  of  the  project  and  the  specific  product  being  developed. 
The  Composite  Development  Center  (CDC)  management  uses  small  round-table  teams  for 
smaller  projects  and  problem  solving.  They  use  Zone  Management  in  the  design  of  the 
P7A  Patrol  Aircraft,  a  much  larger  project  than  those  projects  in  the  Composite 
Development  Center.  Zone  management  is  a  technique  whereby  the  physical  product  being 
designed  is  divided  into  physical  zones.  Each  zone  has  its  own  product  and  process 
definition  team,  responsible  for  all  of  the  requirements  within  its  zone,  and  an  additional 
team  has  the  systems  integration  responsibility  for  all  of  the  interfaces  between  the  zones. 


Problem  solving  teams  can  be  formed  to  address  specific  problems  encountered. 
These  teams  may  or  may  not  be  multifunctional.  A  good  example  of  a  problem  solving 
team,  whose  experiences  led  to  practical  lessons  learned,  was  the  Systems  Integration 
Engineering  (SIE)  Avionics  Rack  Commonality  Working  Group,  a  multifunctional  team 
organized  to  solve  an  avionics  rack  commonality  problem  at  NAD.  Another  type  of  team 
used  by  organizations  practicing  concurrent  engineering  is  one  that  functions  as  a  TQM 
process  improvement  team,  concentrating  more  on  improving  the  process  of  product  and 
process  definition  than  on  ac'  sally  doing  product  and  process  definition. 

C.  TEAM  MANAGEMENT 

Successful  management  of  a  team  relies  on  the  same  types  of  effective  policies  and 
actions  that  make  management  of  an  organization  successful.  A  team  is,  after  all,  a  small 
organization.  Following  are  some  of  the  activities  essential  to  effective  team  management 
(Heany,  1989;  Cleland  and  Kerzner,  1986): 

•  Structuring  of  the  team’s  organizational  design,  i.e.  the  roles,  responsibilities, 
authority,  and  accountability  that  people  are  expected  to  have. 

•  Preparation  of  a  clear,  concise  team  charter  or  mission  statement  stating  the 
problem  the  team  is  to  solve  and  the  boundaries  or  limitations  imposed, 
including  the  schedule  and  the  cost  of  their  process. 

•  Identification  of  the  goals  or  milestones  (characterized  by  specificity  and  time- 
based  measurement  points)  that  the  team  is  expected  to  accomplish  in  working 
toward  its  mission  or  purpose. 

•  Identification  of  the  tasks  required  to  accomplish  the  team’s  purposes. 

•  Delineation  of  the  strategy  of  the  team  to  include  major  policies,  programs, 
procedures,  plans,  budgets,  and  other  resource  allocation  methods  required  to 
facilitate  its  operation. 

•  Identification  of  human  and  nonhuman  resource  support  and  authorization  of 
the  development  and  improvement  of  systems  that  allow  team  members  to  get 
their  job  done. 

The  distinctive  features  of  team  goals  are  their  specificity  and  time-based 
measurement  points-they  tell  the  team  the  magnitude  of  the  progress  they  are  expected  to 
make  (Scholtes,  1989;  Cleland  and  Kerzner,  1986).  Completion  of  all  of  the  goals  within 
the  given  resources  will  accomplish  the  team's  mission.  Goals  can  be  assigned  to 
individual  people  or  to  groups  of  people  on  the  team.  The  team  must  make  use  of  both 
human  and  nonhuman  resources. 
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Trainers  and  facilitators  are  fundamental  human  resources  to  the  team.  Other 
resources  include  the  technical  and  computer  support.  Technical  support  should  include  the 
design,  development,  and  implementation  of  information  systems  to  track  and  report  the 
team  progress.  In  addition,  the  design  and  implementation  of  a  control  system  may  be 
needed  to  monitor  the  team  progress  and,  when  necessary,  reallocate  resources  to  more 
effectively  accomplish  team  objectives  and  goals  (Scholtes,  1989). 

For  the  concurrent  engineering  team  for  the  Advanced  Harpoon  Block  ID  missile 
improvement  at  MDMSC,  a  complete  documentation  package,  prepared  and  distributed  to 
the  team  members  before  the  initiation  of  team  activities,  included- 

•  A  cover  memo,  signed  by  management  at  the  vice  president  level,  explaining 
responsibilities. 

•  The  team  organizational  chart,  showing  the  relationships  among  the  teams. 

•  The  team  definition  and  required  deliverables,  including  a  matrix  of  the 
deliverable  drawings  vs.  the  disciplines  of  the  team  members  illustrating  team 
membership.  The  composition  of  the  team,  however,  was  allowed  to  change 
at  any  time  under  the  direction  of  the  team. 

«  A  Memorandum  of  Agreement  (MOA),  containing  the  philosophy  behind  the 
team  effort,  the  procedures  for  charging  time,  and  the  duties  of  the  team 
members. 

•  The  draft  Standard  Procedures,  defining  the  operational  processes  to  follow 
and  the  computer  systems  to  use. 

•  The  schedule. 

Similarly,  a  Team  Management  Package  was  prepared  for  the  SIE  working  group  at 
NAD  before  the  work  of  the  team  began.  This  package  consisted  of  a  vision  statement,  the 
charter,  the  goals  of  the  team,  the  initial  membership  roster,  the  responsibilities  matrix  for 
the  technical  leader  and  facilitator  (see  Section  D.I.),  a  Quality  Function  Deployment 
(QFD)  matrix,  and  the  task  completion  schedule.  A  detailed  schedule  chart  (e.g.,  Gantt 
chart)  w:,s  not  included,  and  the  group  learned,  as  a  result,  that  a  schedule  of  this  type  is 
essentia!  to  avoid  false  or  missed  deadlines.  The  group  recommended  that  the  QFD  tasks 
be  tied  to  schedule  line  items  in  either  a  Gantt  or  a  critical  path  format.  However,  they 
cautioned  that  the  team  goals  and  schedules  must  be  open  for  redefinition  as  the  issues  and 
the  risks  change  during  the  project.  The  team  must  have  a  certain  amount  of  flexibility  for 
success. 

Regardless  of  the  type  of  organizational  structure  selected  for  concurrent 
engineering  team  formation,  each  team  needs  to  have  a  sponsor.  The  team  sponsor  can  be 
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cither  a  person  or  a  team  of  people  at  the  management  or  supervisor  level,  such  as  a  vice 
president  or  a  steering  committee.  For  projects  that  involve  more  than  one  company,  the 
sponsor  team  should  involve  individuals  from  all  the  companies  involved.  For  example, 
NAD  has  formed  a  management  team  at  the  highest  level  with  representatives  from  the  two 
principal  companies,  NAD  and  McAir,  involved  in  its  Advanced  Tactical  Fighter  (ATF) 
program.  This  management  team  is  the  sponsor  of  all  product  development  teams  involved 
on  the  program. 

The  team  sponsor  supports  the  team’s  activities,  secures  resources,  and  opens 
communication  lines  between  the  team  and  the  rest  of  the  department,  the  division,  and  the 
organization.  Sponsors  should  possess  a  personal  stake  in  the  success  of  the  concurrent 
engineering  effort,  control  over  the  resources  needed  to  launch  and  sustain  the  effort,  and 
the  authority  to  empower  the  team  and  remove  any  roadblocks  to  its  success  (Heany,  1989; 
Cleland  and  Kerzner,  1986).  The  sponsor  can  do  much  to  help  the  concurrent  engineering 
team  overcome  inefficient  processes  imbedded  in  the  culture  of  the  organization.  For 
example,  a  reason  might  once  have  existed  for  extensive  paperwork  between  people  on  a 
project  team.  With  concurrent  engineering,  many  decisions  can  be  reached  through  the 
face-to-face  interaction  of  the  team  members.  Die  extensive  paperwork  may  no  longer  be 
needed,  but  not  only  is  it  required  by  the  organization's  business  practices,  it  is  instilled  in 
the  cultural  practices  of  the  team  members  (Gross,  1990).  The  sponsor  should  help 
remove  these  inefficiencies  to  the  process. 

D.  TEAM  MEMBERSHIP 

Much  of  the  success  of  a  team  is  determined  by  the  choice  of  team  members. 
Concurrent  engineering  teams  may  involve  both  blue  collar  and  white  collar,  union  and 
non-union  workers.  "Achieving  the  required  level  of  teamwork  requires  a  structured 
process  and  competent  people  with  specific  expertise  and  understanding  of  the  product  line, 
users,  technology  base,  materials,  manufacturing  capabilities,  support  capabilities  and  the 
acquisition  process”  (ASD,  1990a),  The  Memorandum  of  Agreement  for  the  concurrent 
engineering  team  for  the  Advanced  Harpoon  Block  ID  improvement  at  MDMSC  stated  that 
the  intent  for  team  membership  is  "to  include  only  those  individuals  who  can  evaluate  the 
soundness  of  the  design  and  viability  of  the  manufacturing  process  of  each  part  or 
assembly  (including:  inspectability,  testability,  reliability  and  maintainability,  procurement, 
and  production)"  (Stevens,  1990).  Individuals  should  be  chosen  for  team  membership 
who  (Heany,  1989)— 

•  See  themselves  as  responsible,  at  least  in  part,  for  the  quality  of  the  product. 
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•  Believe  their  expertise  is  relevant  to  the  product  and  process  definitioa 

•  Believe  the  expertise  of  the  other  team  members  is  relevant  to  the  product  and 
process  definition. 

•  Can  be  trusted  to  approach  the  product  and  process  definition  beyond  a  narrow 
functional  standpoint. 

•  Possess  technical  competence  in  their  special  function  and  the  know-how  to 
gain  access  to  data  or  additional  technical  advice  when  needed. 

One  of  the  lessons  learned  by  the  NAD  SIE  group  was  that  the  critical  factor  for 
membership  on  the  team  is  ownership  of  the  problem.  The  people  selected  for  a  team  must 
be  those  who  are  affected  on  a  daily  basis  by  the  problem  being  addressed  by  the  team. 
The  criterion  proposed  for  selection  is  "the  more  pain  the  better."  Ownership  of  the 
problem  motivates  team  members  to  develop  quality  solutions;  even  if  they  will  not  be 
responsible  for  directly  implementing  a  solution,  they  will  be  affected  by  the  solution. 

Many  of  the  members  from  the  manufacturing  and  support  functions  receive  an 
additional  benefit  by  participating  in  the  product  and  process  definition  team-tlieir  own 
jobs  may  be  easier  to  perform  or  their  own  efficiency  may  increase.  By  participating  on  the 
team,  these  members  no  longer  have  to  wait  for  a  completed  design  before  they  can 
perform  their  job.  As  team  members,  they  provide  continual  design  influence.  In  general, 
members  of  a  concurrent  engineering  team  find  the  experience  to  be  both  stimulating  and 
difficult.  Enthusiasm  for  the  process  was  evident  at  all  of  the  companies  that  the  authors 
visited  for  this  study. 

Since  the  GDLS  M1A2  high-level  concurrent  engineering  team  is  primarily  a 
systems  integration  team  whose  individual  members  sit  on  various  product  and  process 
definition  teams,  the  team  members  spend  most  of  their  time  communicating.  GDLS  has 
found  that  managers  are  the  best  choices  for  this  high-level  concurrent  engineering  team. 
These  managers  have  served  as  the  facilitators  for  the  total  concurrent  engineering  team  of 
teams,  and  their  positions  have  helped  them  surface  problems  to  bring  to  the  attention  of  the 
teams.  GDLS  has  supplied  these  managers  with  additional  administrative  support  so  that 
they  have  the  time  to  adequately  perform  their  concurrent  engineering  function.  The 
product  and  process  definition  teams  or  the  problem  solving  teams  normally  comprise  non¬ 
management  people,  because  they  are  actually  doing  the  definition  work. 

The  formation  of  a  product  and  process  definition  team  carries  with  it  no  guarantee 
that  team  members  will  talk  to  one  another.  The  team  must  include  the  right  leader,  as  well 
as  the  right  team  members.  When  Westinghouse  Electronic  Systems  Group  first 
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implemented  concurrent  engineering,  the  manufacturing  people  did  not  persevere  in 
pointing  out  problems  they  saw  in  the  design,  perpetuating  the  notion  that  engineering 
design  was  the  kingpin  function  of  the  organization.  In  all  organizations,  management 
must  cultivate  an  atmosphere  that  allows  people  to  perform  as  equals  on  the  teams. 
Westinghouse  eventually  cultivated  such  an  atmosphere  and  as  a  result  successfully 
redesigned  a  wired  chassis  assembly  for  the  Airborne  Self- Protection  Jammer  (ASPJ/ALQ- 
165)  (McAfee,  1990). 

1 .  Team  Leadership 

The  team  leader  is  the  team  member  responsible  for  managing  the  team.  His  or  her 
duties  include  (Scholtes,  1989) — 

•  Calling  and  directing  all  team  meetings. 

•  Orchestrating  all  team  activities. 

•  Overseeing  the  preparation  of  reports,  presentations,  meeting  agendas  and 
minutes. 

•  Handling  or  assigning  administrative  detail. 

•  Ensuring  timely  analysis  and  resolution  of  technical  decisions. 

Team  leaders  are  often  supervisors  or  managers  and  are  usually  responsible  for  the 
technical  content  of  the  product  and  process  definition.  The  team  leader  is  a  full-fledged 
team  member  who  shares  the  responsibilities  of  attending  meetings,  carrying  out 
assignments  between  meetings,  and  generally  sharing  in  the  team's  work.  In  addition,  the 
team  leader  is  the  point  of  communication  between  the  team  and  the  rest  of  the  organization, 
specifically  the  team  sponsor. 

The  product  development  teams  at  NAD  have  two  leadership  roles-product  and 
process— performed  by  the  Technical  Leader  and  the  Facilitator,  respectively.  Both  the 
technical  leader  and  the  facilitator  are  responsible  to  the  Management  Team.  The  technical 
leader  has  the  responsibility  for  the  technical  package  that  will  be  delivered  at  the  end  of  the 
team  deliberations,  and  the  facilitator  has  the  responsibility  for  the  administrative  package. 
The  technical  leader  and  the  facilitator  of  the  NAD  SIE  group  worked  together  to  generate 
the  initial  membership  list  prior  to  the  first  meeting.  This  list  was  reviewed  and  open  to 
modification  throughout  the  life  of  the  team  as  priorities  and  risks  in  the  project  changed. 
The  team  found  involvement  of  all  necessary  people  essential  because  working  with  an 
incomplete  membership  results  in  discord  between  divisions  (or  companies)  and  among 
team  members. 
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2.  Collocation1 


One  organizational  element  that  has  proven  successful  for  many  of  the  concurrent 
engineering  teams  is  collocation  of  the  team  members.  The  benefits  of  the  collocation 
include  (Little,  1990)-- 

•  Fostering  of  informal  communication  among  team  members. 

•  Reduction  in  functional  allegiance,  adversarial  relationships. 

•  Cultivation  of  flexible  relationships,  appreciation  of  each  other's  concerns. 

•  Creation  of  a  participative  atmosphere  in  the  work  place. 

Often  the  collocated  members  of  concurrent  engineering  teams  change  over  the 
duration  of  the  project.  (At  all  times,  however,  each  team  member  remains  responsible  and 
accountable  for  the  product  and  process  definition.)  As  its  work  progresses,  the  concurrent 
engineering  team  may  recruit  new  people  to  solve  specific  problems.  Originally  all  the  team 
members  may  be  col.jcated,  but  as  the  size  of  the  team  grows,  collocation  of  all  the  new 
members  ma;  not  be  possible.  The  GDLS  Ml  A2  concurrent  engineering  team  began  with 
about  22  people  and  grew  to  include  about  100  people.  Originally  all  the  team  members 
were  collocated  (same  building,  same  floor),  but  as  the  size  of  the  team  increased, 
collocation  of  all  the  new  members  became  difficult.  At  some  point  a  concurrent 
engineering  team  (team  of  teams)  may  become  so  large  that  many  of  the  benefits  of 
collocation  are  no  longer  realized-a  person  is  limited  in  how  many  other  people  he  or  she 
can  informally  communicate  with  in  any  given  time  period 

With  Zone  Management  at  LASC,  all  the  team  members  of  a  particular  zone  are 
collocated  to  facilitate  daily  communication.  The  concurrent  engineering  teams  at  MDMSC 
and  McAir  are  also  collocated  as  much  as  possible  to  ensure  that  team  members  learn  about 
other  members'  concerns  by  talking  directly.  (If  a  team  member  spent  more  than  half  their 
time  on  the  Block  ID  effort,  they  were  collocated  with  the  group.) 

An  obstacle  to  the  easy  implementation  of  concurrent  engineering  in  many  current 
weapon  system  programs  is  that  the  product  development  involves  not  only  many 
functional  divisions  in  one  company,  but  also  many  different  companies.  Collocation  was 
deemed  so  important  for  the  work  on  the  Light  Helicopter  Experimental  (LHX),  that  Bell 
Helicopter  Textron,  Inc.,  relocated  people  from  Texas  to  Mesa,  Arizona,  to  be  on  site  wtith 
McDonnell  Douglas  Helicopter  Company. 


1  This  is  the  spelling  of  the  word  in  the  dictionary  that  means  "to  set  side  by  side."  Many  people  prefer 
to  use  the  term  co-locate. 
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E.  TEAM  MEETINGS 


Effective  team  meetings  are  one  of  the  team's  best  opportunities  to  enhance  the  team 
building  process  and  make  progress  toward  accomplishing  the  team  goals.  To  enhance  the 
effectiveness  of  team  meetings,  the  following  procedures  are  recommended  (Heany,  1989; 
Cleland  and  Kerzner,  1989): 

•  Limit  the  duration  of  team  meetings--three  to  four  hours  at  most. 

•  Use  agendas  and  record  minutes. 

•  Do  not  end  a  meeting  without  specifying  and  assigning  the  action  items. 

•  Let  no  more  than  two  weeks  elapse  between  meetings. 

•  Insist  on  attendance  of  all  relevant  parties. 

•  Allow  no  phone  calls  or  other  interruptions  during  a  work  session. 

One  of  the  companies  consulted  for  this  study  pointed  out  that  when  conducting 
regularly  scheduled  meetings,  people  attempt  to  do  everything  inside  the  meeting.  It  is 
important  for  the  team  to  take  care  of  those  items  that  need  all  the  team  members’ 
knowledge  during  the  meeting,  but  team  members  must  realize  there  is  still  a  lot  of  work  to 
do  outside  of  the  meetings. 

Discipline  is  an  important  element  contributing  to  the  success  of  concurrent 
engineering  team  meetings  and,  thus,  to  the  team  itself.  Companies  emphasize  that  each 
meeting  should  be  held  for  a  purpose  and  not  merely  just  to  have  a  meeting.  The  regularly 
scheduled  meetings  of  the  concurrent  engineering  teams  at  MDMSC  started  out  at  once  a 
week  for  one  hour.  The  frequency  of  the  meetings  is  flexible,  however,  based  on  the  team 
leader's  judgment.  Even  when  concurrent  engineering  teams  meet  every  day,  such  as  for 
the  GDLS  M1A2,  the  meetings  are  focused.  Meeting  activities  are  strictly  limited  to  the 
agenda  items,  and  all  of  these  activities  have  a  deliverable  focus.  In  addition,  what  is  said 
is  strictly  recorded.  Such  meeting  documentation  should  exist  for  all  of  the  meetings  as 
well  as  the  management  and  program  reviews.  The  following  sections  elaborate  on  some 
of  the  critical  elements  to  team  meeting  success,  and  the  next  chapter  describes  computer 
support  that  could  contribute  to  that  success. 

1.  Agenda  and  Minutes 

All  companies  visited  for  this  study  attributed  the  success  of  their  team  meetings  to 
the  discipline  attained  through  the  strict  adherence  to  a  meeting  agenda  and  the  reliable 
preparation  of  meeting  minutes.  The  agenda  is  prepared  by  the  team  leader  and  distributed 
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to  team  members  in  advance  of  the  concurrent  engineering  team  meetings.  The  agenda 
includes  the  scheduled  action  items,  the  presentation  items  and  times,  and  the  meeting 
attendee  requirements,  based  on  the  action  items  to  be  covered  at  the  meeting.  At  MDMSC 
the  team  members  are  empowered  to  decide  whether  they  are  needed  at  the  meeting  or  not. 
The  team  leader  has  the  right  to  invite  those  he  deems  should  be  present  at  the  meeting. 

The  minutes  of  the  meeting  contain  the  action  items  with  their  status,  tfc.'  closure 
dates,  and  the  assignees.  After  each  meeting  the  minutes  must  be  completely  and  promptly 
compiled,  printed,  and  distributed  along  with  all  presentation  materials  from  the  meeting. 
The  NAD  SHE  group  distributed  the  team  meeting  minutes  not  only  to  the  meeting  attendees 
but  also  to  each  team  member's  management  and  staff  organizations.  Team  members  were 
thus  encouraged  to  fully  participate  in  the  meetings  and  provide  presentations,  since  the 
members  received  recognition  for  their  team  performance  and  activities  by  their 
management.  The  meetings  at  MDMSC  are  open  and  team  members  can  bring  other 
personnel  they  feel  would  be  productive  based  on  the  agenda  items.  The  minutes  should 
record  the  attendance  of  these  additional  or  new  people  (Stevens,  1990).  All  team  leaders 
and  associated  management  of  the  various  teams  organized  around  a  specific  discipline 
received  the  minutes  of  the  meetings  of  each  team.  At  some  level  of  detail,  all  relevant 
personnel  need  to  know  the  activities  of  the  other  teams.  As  new  people  join  a  concurrent 
engineering  team,  they  should  receive  or  have  access  to  all  meeting  documentation  and  the 
initial  team  management  documents. 

2.  Facilitator  and  Recorder 

The  literature  on  effective  team  meetings  usually  describes  two  roles  that  support 
the  meetings:  facilitator  and  recorder.  The  facilitator  has  expertise  in  group  dynamics  and 
group  problem  solving  methods  and  concentrates  on  the  process  of  the  team  meeting  rather 
than  the  technical  content.  This  person  performs  the  roles  of  catalyst  and  diplomat, 
defusing  personal  conflicts  and  converting  differences  of  opinion  into  positive  action.  The 
ideal  facilitator  quickly  learns  to  converse  with  team  members  using  their  terminology.  A 
facilitator  can  be  brought  in  from  outside  the  company  or  selected  from  within  the  company 
and  specially  trained.  Alternatively,  all  team  members  can  be  trained  in  facilitation  skills, 
and  a  different  team  member  can  perform  the  facilitator  functions  at  each  meeting.  In 
industry,  the  initial  implementation  of  concurrent  engineering  usually  includes  the 
assignment  of  a  facilitator  or  coach  from  a  support  division  within  the  organization  to  the 
concurrent  engineering  team.  Tnese  facilitators  or  coaches  are  often  specially  trained 
middle  managers  (Holpp,  1989)  who  usually  have  facilitation  duties  outside  of  the  team 
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meetings  as  well.  At  NAD.  the  facilitator  is  viewed  in  a  co-leadcrship  role,  responsible  for 
the  administrative  package. 

When  a  team  member  functions  as  a  facilitator,  he  or  she  must  act  as  a  neutral 
servant  of  the  team  and  refrain  from  evaluating  or  contributing  ideas  during  the  meeting. 
The  facilitator's  responsibilities  during  the  meeting  include  (Scholtes,  1988;  Doyle  and 
Strauss,  1976)-- 

•  Keeping  the  discussion  focused  on  the  topic  and  progressing  according  to  the 
agenda. 

•  Intervening  if  the  disejssion  fragments  into  multiple  conversations. 

•  Tactfully  preventing  anyone  from  dominating  or  being  overlooked. 

•  Bringing  the  discussion  to  a  close. 

The  facilitator  usually  is  responsible  for  the  meeting  logistics,  although  this  responsibility 
may  fall  on  tiie  team  leader. 

The  recorder  at  a  meeting  is  the  scribe  who  records  the  minutes  of  the  meeting. 
Bringing  in  a  recorder  from  outside  the  team  is  difficult  because  the  recorder  must  have  an 
understanding  of  the  technical  language  of  the  team  in  order  to  summarize  it  and  record 
what  is  important.  A  visual  means  of  seeing  what  is  recorded  is  valuable  so  that  the  team 
members  can  ensure  that  the  ideas  are  recorded  accurately.  The  recorder,  like  the 
facilitator,  must  be  a  neutral,  non -evaluating  servant  of  the  team  during  the  meeting,  even  if 
the  duties  of  recorder  are  rotated  among  the  team  members.  The  recorder  must  be  careful 
not  to  alter  the  meaning  of  any  team  member's  contribution  when  capturing  the  key  points 
of  the  meeting.  The  team  members  at  the  meeting  have  the  responsibility  of  keeping  the 
facilitator  and  the  recorder  in  their  neutral  roles  (Scholtes,  1988;  Doyle  and  Strauss,  1976). 
The  facilitator  and  recorder  have  the  responsibility  of  arriving  early  and  setting  up  the 
meeting  room  (Doyle  and  Strauss,  1982;  Scholtes,  1989). 

At  MDMSC,  the  facilitation  and  recording  tasks  are  performed  by  coaches  who  are 
based  in  a  support  division  in  the  organization  (Integrated  Design,  Manufacturing,  and 
Support  Technology)  but  assigned  ad  hoc  to  the  concurrent  engineering  teams.  It  is  the 
coach's  responsibility  to  run  the  meetings  and  prepare  the  minutes.  Between  meetings  the 
coach  and  the  team  leader  work  together.  The  coach  is  responsible  for  recording  and. 
distributing  the  minutes,  which  contain  the  action  items,  the  assigned  responsible  party, 
and  the  due  dates.  Each  coach  records  the  minutes  in  their  own  preferred  way-MDMSC 
has  not  found  it  necessary  to  have  minutes  in  a  standard  form  or  recording  format,  although 
a  standard  form  is  recommended  in  the  literature  on  meetings  (Doyle  and  Strauss,  1982). 
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At  General  Dynamics  Land  Systems,  the  leader  of  the  M1A2  concurrent 
engineering  team  has  had  the  ultimate  responsibility  for  all  of  the  meeting  records.  The 
facilitator  function  has  rotated  among  the  team  members,  helping  everyone  develop  a  sense 
of  ownership  and  control.  The  primary  reason  the  GDLS  M1A2  concurrent  engineering 
team  has  kept  tangible  records  of  all  team  activities  is  that  such  record  keeping  helps  the 
team  members  understand  what  they  really  did— not  just  what  they  think  they  did  (Diaz, 
1990). 

3.  Meeting  Room 

Having  a  single  designated  room  for  all  of  the  team  meetings  helps  focus  the  team 
members.  The  concurrent  engineering  team  for  the  GDLS  M!A2  has  held  its  daily 
meetings  in  what  it  calls  a  control  room.  All  open  action  items  and  those  persons 
responsible  are  posted  on  the  walls.  The  complete  schedule  and  process  diagrams  are  also 
displayed,  as  well  as  any  other  useful  or  motivational  information.  Having  a  control  room 
helps  build  team  spirit  because  it  is  the  team's  home  room.  They  w'ould  like  to  have  the 
ability  to  gather  around  a  computer  screen  in  the  control  room,  but  they  currently  do  not 
have  good  high-resolution  graphics  screens  available  in  the  room  (Diaz,  1990).  The 
following  chapter  describes  various  types  of  computer  support  that  could  be  used  in  the 
meeting  room. 


IV.  COMPUTER  SUPPORT  OF  CONCURRENT 
ENGINEERING  TEAM  MEETINGS 


Many  of  the  significant  improvements  attributed  to  concurrent  engineering  come 
from  changes  in  the  management  of  the  product  and  process  definition  activities  rather  than 
advances  in  computer  technology.  If  the  philosophy  and  principles  guiding  the  company’s 
behavior  are  wrong,  no  amount  of  effort  or  additional  resources,  including  automation,  will 
keep  the  company  competitive.  However,  computers  will  continue  to  have  a  significant 
role  in  all  types  of  work.  Improving  existing  applications  of  computer  technology--and 
finding  new  ones--will  certainly  become  part  of  most  organizations'  continuous 
improvement  activities.  A  growing  number  of  researchers  arc  exploring  ways  to  combine 
communication,  computer,  decision,  and  group  process  technologies  and  methodologies  to 
support  meetings.  The  computer  support  can  be  as  simple  as  computer-controlled 
audiovisuals  or  as  complex  as  specially  designed  meeting  rooms  with  elaborate  computer 
networks. 

The  traditional  concept  of  a  meeting  is  two  or  more  people  assembled  for  a  common 
purpose.  Technological  advances  have  eliminated  the  nccJ  in  some  cases  to  physically 
assemble  in  a  traditional  meeting  setting.  Technology  has  created  several  new  types  of 
meetings  such  as: 

•  Teleconferencing  -  voice  meetings. 

•  Video-conferencing  -  voice  and  picture  meetings. 

•  Computer  network  conferencing  -  text  and  graphics  meetings. 

This  chapter  focuses  on  the  computer's  role  in  support  of  the  concurrent 
engineering  team  in  traditional  (face-to-face)  meetings.  Proposed  methods  of  introducing 
computer  support  for  meetings  cover  a  wide  spectrum  from  the  use  of  software  designed 
for  a  single  user  (e.g.,  word  processing,  spreadsheets)  to  the  use  of  elaborate  meeting 
rooms  that  provide  a  computer  for  every  participant.  The  basic  concepts  behind  these 
approaches  are  presented  in  the  following  paragraphs  with  references  to  more  detailed 
descriptions. 


A.  SINGLE-USER  SOFTWARE 

This  chapter  describes  three  approaches  to  computer  support  for  meetings.  The 
first  approach  is  to  simply  use  software  designed  for  single  users  during  a  meeting.  This 
approach  is  probably  the  easiest  to  introduce  and  certainly  the  least  expensive.  The  concept 
is  to  use  the  same  computer  software  during  the  meetings  that  increases  the  productivity  of 
individual  team  members  in  their  offices.  The  computer,  software,  and  trained  operator  are 
already  available  and  only  need  relocation  into  a  room  big  enough  to  comfortably  hold  the 
team.  If  the  computer  monitor  is  not  large  enough  for  everyone  to  see,  then  either  a  larger 
monitor  or  a  computer  projection  system  can  be  used.  Another  option  is  to  interconnect 
several  small  monitors.  With  this  approach  the  computer  can  be  used  to  capture  and 
organize  textual  or  graphical  information,  as  a  dynamic  presentation  device,  or  for 
performing  analyses  or  assessments.  A  visual  means  of  seeing  what  is  recorded  is  valuable 
because  the  team  members  can  ensure  an  accurate  recording  of  the  ideas.  Many  of  the 
teams  we  visited  expressed  a  desire  to  have  a  monitor  in  the  room  to  view  the  graphics  and 
analyses. 

A  good  reference  for  this  approach  is  Bernard  DcKoven’s  book.  Connected 
Executive  (DeKoven,  1990).  The  primary  software  he  promotes  for  use  during  meetings  is 
the  outline  processor.  As  expected,  an  outline  processor  is  a  software  program  designed  to 
create  and  manipulate  outlines.  The  key  feature  of  this  type  of  software  is  the  case  with 
which  the  outlines  can  be  changed.  DeKoven  describes  how  the  outline  processor  can  be 
used  in  developing  agendas,  creating  documents,  capturing  major  themes  from  the 
discussion,  supporting  debate,  and  producing  instant  minutes.  DeKovcn’s  central  strategy 
to  facilitate  the  introduction  of  computers  into  meetings  is  the  creation  of  a  new  role,  that  of 
the  technographer.  The  tcchnographcr  uses  the  computer  during  meetings  to  help  a  group 
of  people  focus,  express,  clarify,  and  organize  their  ideas.  The  technographer  must 
possess  more  than  hardware  and  software  skills- -he  or  she  must  be  able  to  respond 
appropriately  to  the  ever  changing  needs  of  the  group  being  supported.  This  role  is  an 
enhancement  on  the  role  of  recorder.  "As  the  meeting  facilitator  is  competent  in  techniques 
for  facilitating  the  process  of  the  meeting,  and  the  [leader)  has  content  knowledge,  the 
technographer  facilitates  the  product."  (DeKoven,  1990) 

There  are  many  software  products  for  personal  computers  that  facilitate  the  creation 
of  presentations.  Many  of  these  products  allow  the  computer  to  be  used  as  an  electronic 
slide  projector.  Using  the  computer  this  way  eliminates  the  need  to  create  overheads  or 
35mm  slides.  Furthermore,  the  presentation  material  can  be  easily  modified  based  on 
audience  feedback.  The  Computer-Aided  Design  (CAD)  workstation  of  the  design 
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engineer  using  three-dimensional  (3D)  solid  modeling  is  another  convenient  presentation 
device  for  concurrent  engineering  teams  to  use.  The  ability  to  fotate  and  magnify  areas  of 
interest  is  especially  valuable  in  allowing  the  design  engineer  to  communicate  his  work  to 
the  other  specialists  on  the  team. 

There  are  few  limits  on  this  approach  of  using  software  designed  for  a  single  user 
to  support  concurrent  engineering  team  meetings.  Other  ideas  include  using  project 
management  software  or  spreadsheets  for  budgeting  and  providing  access  to  the  evolving 
common  repository  of  design  data. 

B.  SINGLE-OPERATOR  SOFTWARE 

The  second  approach  is  the  use  of  software  designed  for  group  decision  support 
that  resides  on  a  single  computer  operated  by  an  individual.  The  Decision  Techtronics 
Group  (DTG)  at  the  State  University  of  New  York  in  Albany  has  developed  an  approach  to 
solving  complex  problems  they  call  Decision  Conferencing.  "Decision  conferences  are 
designed  for  groups  that  need  to  reach  consensus  on  complex  decisions  for  which  there  is 
no  'formula'  or  objective  solution  but,  nonetheless,  must  be  made  on  time,  in  spite  of 
information  gaps  and  uncertainty"  (Schuman,  1987).  Decision  conferences  combine 
computer-based  analytic  decision  modeling  and  group  facilitation  methods  in  order  to 
enhance  the  productivity  of  the  group.  In  addition  to  the  facilitator  and  recorder  functions, 
a  Decision  Conference  requires  the  use  of  an  analyst  to  build  the  mathematical  model  from 
the  ideas  generated  by  the  group. 

Interactive  Management  (IM)  is  another  computer-assisted  group  problem  solving 
technique  that  was  developed  at  George  Mason  University  in  Fairfax,  Virginia.  IM 
combines  consensus  methodologies-which  provide  the  opportunity  for  focused  open 
dialogue  in  structuring  ideas,  designing  alternatives,  and  making  trade-offs-and  software, 
all  based  on  sound  behavioral  and  technical  principles.  The  computer  programs  arc  used  to 
efficiently  derive  structural  maps  illustrating  relationships  among  ideas  and  to  perform 
trade-off  analyses  with  both  qualitative  and  quantitative  attributes  (Christakis  and  Keever, 
personal  communication).  IM  has  been  shown  to  effectively  elicit  and  combine  the 
expertise  of  a  design  team.  In  late  1983,  a  Department  of  Defense  (DoD)  tri-Setvice  task 
force  was  formed  to  demonstrate  the  technology  base  feasibility  of  developing  three 
different  strategic  defense  systems.  The  task  force  worked  intermittently  for  6  months 
without  producing  any  useful  conceptual  designs  for  the  space-based  laser  system.  The 
task  force  leader  decided  to  try  the  IM  approach,  and  after  28  hours  of  group  work,  an 
acceptable  conceptual  design  was  completed  (Christakis,  1983). 
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Boothroyd  and  Dewhurst's  Design  for  Assembly  (DFA),  a  method  for  evaluating 
the  ease  of  assembly  of  design  alternatives,  is  an  example  of  analysis  software  that  can  be 
used  in  a  team  setting.  Questions  posed  by  the  software  are  answered  by  consensus  of  the 
product/process  team  (composed  of  both  design  and  manufacturing  engineers),  but  the 
software  resides  on  a  computer  that  is  operated  by  an  individual  team  member.  The  method 
uses  quantitative  analysis  to  focus  the  group’s  efforts  and  draw  on  the  creative  power  and 
expertise  of  individual  team  members.  The  quantification  of  design  factors  aids  the  group 
interaction  process  in  team  design  activities,  since  the  group  must  reach  a  consensus  on  the 
measurement  ratings  used  to  assess  a  design  alternative's  ease  of  assembly. 

The  training  sessions  required  for  the  proper  use  of  DFA  stress  that  computer  tools 
needed  for  simultaneous  engineering  must  support  the  human  interaction  that  occurs  during 
the  concurrent  engineering  team  problem  solving  process-stimulating  the  creativity  and 
learning  of  team  members,  helping  them  arrive  at  consensus,  and  enabling  them  to  make 
estimates  when  hard  quantifiers  are  not  available.  Software  used  in  a  group  setting  must 
also  be  quick-the  key  to  consistent  measurements  made  by  a  group  is  rapid  iteration.  Used 
properly,  the  group  process  of  using  the  computer  tool  should  be  as  valuable  as  the 
analytical  results  derived  from  its  use  (Cralley,  Dierolf,  and  Richter,  1990). 


C.  DECISION  ROOMS 

The  third  approach  to  computer  support  for  meetings  is  to  use  computer-supported 
decision  rooms  (AIRMICS,  1989;  Turner,  1989;  Dierolf  and  Richter,  1989).  These 
rooms,  often  referred  to  as  Group  Decision  Support  Systems  (GDSS),  provide  each 
meeting  participant  a  personal  computer  or  terminal.  Specially  designed  software  assists 
the  group’s  problem  solving  activities.  The  immediate  benefit  of  this  approach  is  the 
structure  it  provides  to  the  meeting  process.  An  eventual  benefit  of  this  approach  is  the 
possible  elimination  of  the  need  for  physical  collocation  of  the  meeting  participants.  It  must 
be  stated,  however,  that  these  rooms  are  best  considered  research  laboratories.  Much  of 
the  empirical  research  has  produced  inconsistent  results  about  the  benefits  of  this  approach. 

Only  one  of  the  companies  visited  during  the  course  of  this  study  had  extensive 
plans  for  using  computers  to  support  its  concurrent  engineering  team  meetings.  Lockheed 
Aeronautical  Systems  Company  (LASC)  has  developed  a  meeting  environment  for  its 
concurrent  engineering  teams  that  affords  each  team  member  access  to  the  same  computer 
hardware  and  software  used  in  their  own  workspace.  LASC  calls  this  environment  the 
Computer  Integrated  Manufacturing  (CIM)  Roundtable.  While  the  environment  is 
complete-including  the  computer  network-it  has  had  only  limited  use  for  actual  design 
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complete— including  the  computer  network-it  has  had  only  limited  use  for  actual  design 
meetings.  The  networking  component  has,  however,  facilitated  more  extensive  and  rapid 
experimentation  with  the  solids  model  by  the  maintainability  engineers,  resulting  in  better 
quality  preliminary  design. 

The  concurrent  engineering  teams  at  National  Cash  Register  (NCR)  Corporation 
hold  weekly  meetings  with  on-screen  reviews.  These  meetings  are  called  limited 
distributed  meetings  because,  although  they  are  all  in  the  same  room,  team  members  may 
be  grouped  around  deferent  computer  terminals  in  the  room.  NCR  Corporation  has  found 
that  computer  support  delivering  detailed  design  information  to  all  team  members  has  had 
both  benefits  and  disadvantages.  Such  support  has  allowed  the  team  members  a  private 
review  of  the  design  information  at  their  desks,  enabling  them  to  prepare  more  thoroughly 
before  the  team  meetings.  However,  having  the  information  at  their  desks  caused  many 
users  to  throw  the  electronic  images  "over  the  wall"  in  much  the  same  way  that  the 
engineering  drawings  once  were  in  companies  practicing  engineering  design  as  a  sequential 
(instead  of  integrated)  process.  Moreover,  this  ability  led  some  to  believe  that  they  did  not 
need  to  attend  the  meetings.  Vigilance  is  required  to  ensure  that  all  team  members  come  to 
all  the  meetings.  The  effective  product  team  will  move  from  a  review-oriented  process 
toward  direct  participation  in  product  and  process  definition  (Wallach,  1990). 


V.  FINDINGS  AND  RESEARCH  RECOMMENDATIONS 


Specific  concurrent  engineering  practices  vary  among  organizations.  There  are, 
however,  various  management  practices  that  appear  to  work  well  for  most  organizations. 
This  paper  has  presented  the  reader  with  useful  examples  from  several  defense  contractors 
illustrating  how  concurrent  engineering  teams  are  being  organized  and  managed  and  how 
concurrent  engineering  team  meetings  are  conducted  and  supported.  It  has  also  identified 
types  of  computer  support  for  concurrent  engineering  team  meetings  that  could  be  used  to 
enhance  the  organization  and  management  of  these  meetings.  Many  of  the  applications  of 
computer-aided  group  problem  solving  are  possible  and  practical  today. 

This  chapter  summarizes  the  general  findings  from  the  study  and  identifies  areas 
determined  to  require  further  research. 

A.  GENERAL  FINDINGS 

1 .  Relationship  Between  Total  Quality  Management  and  Concurrent 
Engineering 

While  one  could  argue  that  concurrent  engineering  can  be  done  in  organizations  that 
do  not  embrace  Total  Quality  Management  (TQM),  the  authors  found  no  examples  where 
this  is  the  case.  This  finding  is  consistent  with  the  finding  of  the  DoD/Industry  Task  Force 
on  Concurrent  Engineering  that  companies  have  attained  the  integrated  concurrent 
engineering  process  by  applying  TQM  principles  to  their  engineering  process  (Costello, 
1989).  The  TQM  literature  provides  valuable  information  about  process  analysis  and  the 
use  of  teams  for  process  improvement,  and  it  should  be  consulted  by  organizations 
interested  in  concurrent  engineering.  Implementation  of  TQM  should  precede  the 
implementation  of  concurrent  engineering.  TQM  provides  a  holistic  approach  toward 
improving  an  organization  that  takes  into  account  the  people  that  make  up  the  company,  the 
corporate  history,  existing  policies  and  procedures,  and  existing  support  systems.  While 
there  may  be  similarities,  each  implementation  of  TQM  and  concurrent  engineering  is 
unique  in  that  each  organization  begins  at  a  different  point. 

While  this  is  not  the  first  time  this  relationship  has  been  identified,  the  authors  have 
found  that  the  promoters  of  concurrent  engineering  and  TQM,  both  in  industry  and  in  DoD, 
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are  often  from  separate  organizations.  It  is  important  that  the  promoters  of  these  two  key 
initiatives  recognize  the  close  relationship  between  TQM  and  concurrent  engineering  and 
provide  consistent  guidance  to  prevent  diluting  resources. 

2 .  Communication  as  the  K2y  to  Concurrent  Engineering 

The  benefits  of  concurrent  engineering  are  primarily  derived  from  enhanced 
communication.  All  companies  stressed  the  importance  of  clear,  concise  statements  of  the 
team's  mission,  goals,  resources,  and  constraints;  accurate  but  concise  recording  of  the 
team  activities  distributed  to  all  relevant  people  in  the  organization;  and  ongoing  briefings  of 
team  progress  to  other  stakeholders.  The  collocation  of  the  team  members  allows  them  to 
communicate  on  a  daily  basis  and  to  gain  an  understanding  of  each  other's  perspective. 

3.  Computer  Support  for  Team  Meetings 

Based  on  the  site  visits  and  a  further  review  of  the  literature,  the  authors  stand  by 
the  finding  from  their  1989  report  (Dierolf  and  Richter,  1989)  that  computer  support  for 
meetings  represents  an  opportunity  to  enhance  the  effectiveness  of  concurrent  engineering 
teams.  There  are  a  variety  of  ways  computers  can  support  concurrent  engineering  team 
meetings.  In  the  near  term  this  support  will  most  likely  be  through  software  designed  for 
single-users  being  employed  in  group  settings.  The  more  elaborate,  multiple  computer 
support  systems  warrant  further  research,  especially  in  recognition  of  their  demonstrated 
success  in  the  face-to-face  group  support  in  business  applications  and  their  potential  to 
support  physically  separated  teams.  A  key  requirement  for  any  computer  system  that 
supports  concurrent  engineering  meetings  is  that  it  integrates  efficiently  with  the  other 
computer  systems  that  support  the  concurrent  engineering  team  (e.g.,  Computer-Aided 
Design,  engineering  data  management). 

Most  of  the  research  in  computer  support  for  meetings  is  technology  driven.  The 
need  for  the  computer  is  assumed.  When  the  use  of  the  computer  is  a  given,  the  problem 
becomes  one  of  figuring  out  how  best  to  apply  this  technology.  The  fact  that  the  authors 
uncove*ed  only  one  piece  of  literature  that  discussed  when  not  to  use  computers  supports 
this  find  ng  (Gerstein,  1990).  Computer  support  for  meetings  must  consider  the  behavioral 
as  well  ?s  the  technical  aspects  of  group  problem  solving.  The  goal  should  be  to  enhance 
positive  aspects  of  group  work  while  eliminating  the  negative  features.  Computers  should 
be  employed  to  do  things  computers  do  well-record,  store,  and  calculate  enabling  people 
to  explore  the  more  creative  aspects  of  problem  solving. 
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The  computer-supported-meeting  research  community  has  the  same  needs  as  those 
identified  by  McGrath  and  Altman  in  their  critique  of  the  small  group  research  field 
(McGrath  and  Altman,  1966).  These  needs  include-- 

•  Theory  and  integrating  concepts. 

•  Intellectual  controversy  and  subjectivity  as  a  research  stimulant. 

•  Research  methods  that  go  beyond  the  laboratory. 

•  Standardization  in  concepts,  terms,  and  operations. 

McGrath  and  Altman  claim  that  many  of  the  problems  associated  with  the  field  come  from 
the  traditions  and  norms  of  the  university  community  and  from  the  methods  used  to  fund 
research.  University  researchers  are  funded  and  promoted  for  doing  unique  work,  so  they 
tend  to  develop  individual  theories,  methods,  and  terms. 

B .  AREAS  FOR  ADDITIONAL  RESEARCH 

During  the  course  of  this  study,  the  authors  identified  many  areas  that  could  benefit 
from  additional  research.  Among  these  are  documentation  of  the  concurrent  engineering 
decision  process,  documentation  of  the  lessons  learned  about  the  concurrent  engineering 
process,  and  evaluation  and  training  of  the  concurrent  engineering  team  members. 

1 .  Documentation  of  the  Decision  Process 

In  IDA's  first  research  report  published  for  the  Unified  Life  Cycle  Engineering 
(ULCE)  program,  Brei  et  al.  identified  one  of  the  desired  architectural  features  of  an  ULCE 
system:  "documentation  of  design  decisions  and  their  rationales  must  be  generated  and 
made  available  to  all  persons  w-ho  will  be  affected  by  these  decisions"  (Brei  et  al.,  1988). 
The  recording  of  the  design  decision  rationale  has  been  a  recurring  theme  in  IDA’s  research 
recommendations  for  the  ULCE  program,  and  it  continues  to  be  an  important  element  for 
the  concurrent  engineering  program. 

Documentation  of  the  concurrent  engineering  team's  efforts  is  especially  important 
because  of  the  iterative  nature  of  the  definition  process.  "The  product  and  process 
definition  teams  must  pursue  multiple  design  approaches,  and  thus  keep  track  of  different 
versions  of  particular  design  solutions  for  each  design  approach"  (Engineer's  Design 
Notebook,  1990).  In  addition,  new  products  are  often  redesigns  of  previous  products. 
The  trail  of  design  decisions  reached  for  a  product  as  well  as  qualitative  empirical 
information,  such  as  the  rules  of  thumb  used  and  the  rationale  behind  the  decisions,  is 
valuable  information  for  any  future  product  and  process  definition  team.  Documentation  of 
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the  rationale  should  include  any  quantitative  information  used  to  reach  it,  such  as  a  trade 
study  analyses.  The  amount  of  detail  contained  in  this  audit  trail  is  open  to  debate,  but 
general  agreement  exists  on  the  fact  that  more  information  than  just  the  design  data  and  the 
final  drawings  must  be  kept  in  a  manageable  form.  Other  team  records,  such  as  meeting 
agendas  and  minutes  and  presentation  materials,  should  also  be  kept  for  complete  process 
documentation. 

Although  most  of  the  companies  visited  for  this  study  recognized  the  need  for 
capturing  the  design  decision  rationale,  and  applications  are  being  developed  in  industry 
and  academia,  this  research  field  is  still  in  its  infancy.  Questions  still  need  to  be  answered 
and  additional  research  needs  to  be  done  on  this  topic.  What  information  is  important  to 
record  and  how  should  the  information  be  captured?  What  forms  of  access  are  required  or 
allowed  for  this  information?  How  should  the  information  be  represented  for  easy 
utilization? 

A  reported  benefit  of  computer  support  for  meetings  is  the  ability  to  document 
decision  rationales,  but  is  the  documentation  produced  by  current  approaches  adequate  for 
product  and  process  definition  projects?  For  example,  the  Design  Journal  from 
Microelectronics  and  Computer  Technology  Corporation  (MCC)  supports  group  design 
deliberation  as  well  as  single-user  design  annotation.  "It  allows  designers  to  attach 
(hypertextually)  design  rationale  (design  decision-making  information)  to  arbitrary  design 
artifacts  that  may  be  geographically  distributed"  ( MCC  Technology  Catalog,  1990).  Can 
this  technology  be  used  effectively  by  concurrent  engineering  teams? 

Researchers  of  the  design  process  have  recognized  that  what  designers  say  they  do 
and  what  they  actually  do  can  be  very  different  (Brei,  Dierolf,  and  Richter,  1989). 
Research  into  methodologies  for  capturing  and  representing  the  decision  rationale  of  the 
product  and  process  definition  should  be  multidisciplinary  (domain  independent)  and 
conducted  in  conjunction  with  those  researchers  who  study  the  design  process  and  the 
information  generated  and  required  during  that  process. 

2.  Lessons  Learned  about  the  Concurrent  Engineering  Process 

The  importance  of  lessons  learned  is  illustrated  by  the  fact  that  a  primary  duty  of 
concurrent  engineering  team  coaches  at  McDonnell  Douglas  Missile  Systems  Company 
(MDMSC)  is  to  capture  the  lessons  learned  by  the  team.  MD?vlSC's  goal  is  to  make  the 
concurrent  engineering  team  self-sufficient  so  that  the  coaches  can  leave  the  team,  but  the 
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coaches  can  leave  the  team  only  when  another  mechanism  is  in  place  to  capture  the  lessons 
learned. 

Another  lesson  learned  at  MDMSC  is  that  tracking  the  problems  is  just  as  important 
as  tracking  the  successes  of  a  concurrent  engineering  team,  and  they  plan  to  record  both  the 
successes  and  the  problems.  The  Northrop  Aircraft  Division  (NAD)  System  Integration 
Engineering  (SIE)  working  group  also  found  that  discussing  the  problems  the  team  might 
encounter  in  accomplishing  their  mission  (gleaned  from  the  lessons  learned)  was  beneficial 
to  the  team  at  the  first  or  second  meeting.  Contrary  to  what  one  might  believe,  NAD  found 
that  bringing  potential  problems  out  into  the  open  is  not  an  inhibitor  to  the  team  process. 

The  lessons  learned  by  an  organization  in  implementing  concurrent  engineering  can 
be  invaluable  to  another  company,  just  as  the  lessons  learned  from  field  data  on  a  particular 
product  are  useful.  The  lessons  learned  doing  concurrent  engineering  should  provide 
information  about  the  process  of  doing  concurrent  engineering— what  works  and  what 
doesn't  work.  These  lessons  learned  need  to  be  documented  in  such  a  way  that  they  can  be 
retrieved  and  analyzed  quickly  and  easily.  General  Dynamics  Land  Systems  (GDLS)  has 
amassed  a  substantial  collection  of  lessons  learned  during  its  M1A2  project,  and  it  would 
be  useful  to  have  this  information  in  a  convenient  form.  Documentation  of  the  lessons 
learned,  however,  requires  answers  to  most  of  the  questions  posed  for  recording  of  the 
decision  rationale.  Research  is  needed  to  develop  a  methodology  for  recording  and 
retrieving  lessons  learned  on  concurrent  engineering.  This  methodology  should  be  useable 
by  any  organization,  but  an  organization  that  already  has  a  considerable  collection  of 
lessons  learned  would  be  best  chosen  as  the  test  case. 

3.  Performance  Evaluation  of  Concurrent  Engineering  Team  Members 

Questions  about  how  to  most  effectively  evaluate  team  members  and  reward  team 
success  were  prevalent  among  the  companies  visited  for  this  study.  The  recommendation 
in  most  of  the  team  building  literature  is  that  the  team  should  be  evaluated  and  rewarded  as 
a  team,  not  just  as  individual  members.  Although  most  companies  realize  this,  it  remains  a 
tough  problem  because  of  the  many  organizational  and  political  issues  encountered  in  trying 
to  implement  such  a  scheme.  The  GDLS  M1A2  concurrent  engineering  team  has  compiled 
a  list  of  excuses  that  people  have  used  to  avoid  taking  concurrent  engineering  seriously  or 
implementing  the  process  with  full  participation  of  all  the  disciplines.  The  first  excuse  on 
the  list  is  that  methods  of  evaluating  performance  are  still  being  established.  Evaluation 
measures  for  success  of  the  team  and  for  the  performance  of  the  individuals  on  the  team 
must  be  developed  and  implemented.  The  ATF  TQM  team  at  NAD  has  spent  4  years  in 
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rigorous  debate  over  what  team  building  and  team  man  tenance  is  all  about.  Guiding 
principles  have  now  been  prepared  for  many  of  the  issues  involved  with  bringing  together  a 
cross-functional  team  including  the  reward  structure  and  revised  career  paths.  Research  is 
needed,  based  on  industry  experiences  such  as  at  NAD,  into  the  kinds  of  performance 
evaluations,  incentives,  and  promotion  considerations  that  best  support  the  functioning  of 
the  concurrent  engineering  teams. 

4.  Training  Requirements  for  Concurrent  Engineering  Team  Members 

Training  required  for  concurrent  engineering  goes  oeyond  traditional  engineering 
analysis  education.  In  fact,  until  engineering  education  adopts  practices  that  contribute  to  a 
concurrent  engineering  environment,  training  is  needed  to  overcome  the  single-disciplinary, 
individualist  thinking.  Employees  need  to  be  trained  in  group  dynamics  and  how  to  work 
as  team  members.  Research  needs  to  be  done  to  define  the  training  requirements  for 
concurrent  engineering.  This  research  should  be  done  in  conjunction  with  research  into 
performance  measures  for  concurrent  engineering  teams,  since  training  that  does  not 
contribute  to  an  employee's  performance  measures  will  not  be  valued  (Holpp,  1989). 
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